Idan Plotnik: [00:00:00] For one customer, we are spending more than 300, 000 repos across five different source control manager. Right now, there is a huge movement from the CICD pipeline and integrating these tools into the pull request, it goes to the COO and the CEO accountability. They need to sign on the software that they produce same as they need to sign or they're on their financial reports.

Ashish Rajan: Welcome to 2024. where applications are filled with multiple languages, multiple CI CD pipelines, multiple pentests, bug bounty findings that you have to keep fixing. This is like the reality of the world we live in, where most applications, whether you build them in cloud or whether you build them in a world where it may just be purely application, you have a lot of complexity these days and in this conversation for people who are probably from a cloud security background and now starting to do devsecops. or probably people who are devsecops [00:01:00] and trying to do cloud security, you'll find valuable information around the insight of how do people do risk management for application at scale? And by the way, I'm going to put some context. When I say risk management, I don't just mean, Hey, that I have an application that I'm ready to build, what my risk posture is, it's more deeper than that. It's more around the fact that I have an application that I created. Let's just call it Cloud Security Podcast. And I am using Java in it, which has a lot of classes, a lot of open source. It's been built in cloud, and it also uses TypeScript, has Terraform, is storing secrets, has microservices, has API.

And the list goes on, that is truly the reality of a lot of modern cloud applications these days that are built in cloud. And if you want to throw multi cloud in there as well, there's an added complexity for that as well. In this conversation with Idan, I was fortunate enough to at least get an understanding of what is the whole like ASPM space, Application Security Posture Manager.

Yes, there is another acronym that Gartner has been kind enough to [00:02:00] release. But the interesting part is Gartner also calls it out that 40 percent of the organizations around the world would end up investing in an ASPM by 2026. And by the way, we're in 2024, so it's only two years. So I want to make sure I had this conversation.

It's almost like for people who really already work with a large repository and large organizations, you will instantly connect with some of the conversations we had for why is there a need for this and why is there a need for me to say. If I already have a CSPM, which does give me the context for cloud, why do I need to include that into a application security context?

Because at the end of the day, first principle folks, people look at us in our organizations for security information about the application. They may or may not really care if it's on AWS or Azure or GCP. What they really care about is by the way, if I deploy this into production right now, would it break my risk posture for cloud?

Would it break my risk posture for application? Would it break my risk posture for open source libraries? It is a lot more complexity to it. And if you're looking at that large [00:03:00] scale, we definitely go into that as well. And we also spoke about at what stage do you really need it? And is it more the maturity that you're after?

If you're someone who's building your program on this in 2024, You probably would, you would want to consider this as part of your conversation that whether you should look at the large complexity that you probably have in your environment, how are you addressing it? All that and a lot more in this episode.

I also wanted to give a shout out to everyone who came and said hello to us at NDC Oslo in a couple of weeks ago, early Jan, it was definitely a great to see that we were in a DevSecOps, AppSec kind of space. We had so many people who were doing cloud security. I made a LinkedIn post around the observation we had, I guess a TLDR version of it is that, it was really interesting to see the large space of Azure deployments in Norway in general, followed by GCP and followed by AWS and how AWS is trying to make a play there. But overall, a lot of people were having mixed skills of DevSecOps in cloud, which is what one of the inspiration for this conversation with Idan Plotnik from Apiiro was as well.

Another news is [00:04:00] that fwd:cloudsec is coming up soon. So if you are based out of Europe and you are one of our community members from the European space, there's a Cloud security conference here in Europe in the coming months more details to come on the fwd:cloudsec website, but definitely check that out.

It's a great place for community to come together and meet other people who do cloud security. And finally, if you are listening to our episode for a second or third time, I would really appreciate if you could take a moment to leave us a review on iTunes or Spotify, if that's where you're listening to this, or if you're watching us on YouTube, give us a thumbs up or LinkedIn thumbs up.

And it really means a lot to us. It takes only a minute from your part, but it means a lot for us to know that, Hey, people care of what we are trying to create. And it also means that people who are trying to grow their cloud security skills, get to find out about, Hey, this is another way for me to learn about cloud security.

So thank you for listening and always supporting us in all these years. And I look forward to serving you guys for many more years to come in the moment, enjoy this episode and I'll see you on the next episode, but talk soon.

Idan, could you share a bit about yourself, man? How did you get into the [00:05:00] whole cybersecurity space?

Idan Plotnik: Absolutely, Ashish, and thank you very much for having me. Basically, in 24 years in the cybersecurity industry, I started as an engineer at the IDF in a cybersecurity unit. Then I had my own consulting services company, doing pentest security code review, risk assessments.

I've sold this company. Started a startup in the identity security space, sold it to Microsoft. And lastly, I was a GM for software engineering, running Defender for Identity at Microsoft. And there I basically felt for the first time how. Complex it is to plan and implement an app sec program that involves risk management as part of the release cycle.

And, the combination between still release fast, but secure. which is some kind of, a mix between them that is complex to implement.

Ashish Rajan: And we're definitely going to get into some of that as well. For some people who [00:06:00] have never heard this word, as for some people who understand, understand what that is, what is ASPM?

Idan Plotnik: So ASPM is an application security posture management. Finally, we have an acronym, after we won the RSA innovation sandbox and got a cool vendor from Gartner. So ASPM basically means mapping and identifying the posture of your application during the development life cycle, right?

Before you deploy to your cloud or to a production environment, that's it in a very short explanation. There is a fine line between while you develop before you've deployed and after you deployed. And the three business outcomes for the ASPM are getting complete visibility into your codebases and software supply chain, which is the source control manager, CICD pipeline, artifactory and others and prioritize all the alerts with a deep understanding [00:07:00] of your application architecture. And we manage the application risk lifecycle with guardrails and measurements and reporting.

So you can decide if you can release or not based on this risk analysis.

Ashish Rajan: Almost like a platform that is an end to end for, I don't know, like I think things like your SCA, SAST, secret management, everything people consider as part of making a decision for, is this safe enough for me to deploy in production?

And to your point, deeper understanding of that code with the architecture context, am I oversimplifying it or would that be almost like a kind of close to accurate information?

Idan Plotnik: So I will say that secret scanning and SCA and.SAST, the API security testing in the code and understanding when to run a threat model or a pentest, which are not scanning tools, but they are still a testing methods that you are doing annually.

All these are like solutions as part of the ASPM [00:08:00] platform, but the ASPM platform needs to provide you much more than that. Just aggregating the tools and aggregating the alerts is, yet,: I don't know if you recall, there was a few years ago, a term called ASOC, application security orchestration, correlation orchestration.

And it didn't work. Why? Because exactly because what you're saying, because just taking all these tools and putting them, putting their alerts in one place without the deep context of how your code is structured, it's meaningless. Okay, and I can give you one example. If I have code module with an API that exposed PII data.

And the SAST scan says that in this specific line of this specific API, there is a SQL injection. And this API is using log4j. Then you need to connect the [00:09:00] dots and without deeply understanding your code architecture and the code components and the relationship between them it's meaningless to say I have log4j plus I have an API that exposes PII.

Ashish Rajan: And I think it also almost opens another box where I was trying to research on this topic. And a lot of also found that a lot of cloud security people talk about this as well, because a lot of people are in devsecops roles.

And I wonder for the cloud security audience, which is the pure cloud security audience, which just does cloud security for them. It's like CSPM and CNAPP. So that is pretty much the solution for it. Isn't that what this does? But what is the difference between an ASPM and a or a CNAPP

Idan Plotnik: So it's exactly the line as I said, between understanding the posture of your cloud architecture and understanding the posture of your application architecture before you deploy for the cloud, it's kinds of, it's easy because everyone understand [00:10:00] that the cloud is runtime and it's there. And when you need to assess the risk posture or security posture of the cloud in the cloud in the application, it's a little bit more complex because the entire secure by design concept is saying you need to find and assess these risks early in the development process before you deployed to reduce the risk as much as you can. So I think this is the fine line between CSPM that is doing the cloud posture management, understanding which containers are exposed and talking to each other.

And where do you have sensitive data in your S3 buckets? The ASPM will tell you how many APIs do I have in my code? How many open source dependencies I have with vulnerabilities? How many secrets in the code I have that are valid? What is the architecture of my [00:11:00] application? How many microservices I have and which one went through which security testing tools and processes?

So if I ready for release, okay, and now I can say, okay, I have 500 modules through 30 of them are going to be exposed to the internet and are high business impact. Why? Because they contains PII data. They went through a SAST. And they went through an SCA scan and secret scanning and they went through a pentesting and they went through a threat model and all of these security testing tools and processes or must be implemented before you release to the cloud.

And this is the line between ASPM and CSPM. I want to tell you that in the real world or in modern applications, this is where the complexity comes into play, where in the venn diagram you have things [00:12:00] that you need from runtime or you need from the code to be able to assess the risk even before you deploy or after when you have the case of log4j

In the venn diagram something that common for both. So this is where the discussion becomes a little bit more, I wanna say complex, right?

Ashish Rajan: And I think the Venn diagram is an interesting example as well because we started out the conversation by saying that it's like a deep understanding of your code.

And these days a lot of people are writing infrastructures code as well, which has a lot of secrets. And there's a whole conversation around the fact that lines are starting to get blurrier. The more applications go into cloud. Complexity keeps adding to what he was saying as well. It's funny, I think we were at NDC Oslo last week and met so many DevSecOps people who have cloud security skills and application security skills. And you go, wait, this is already happening. Like now DevSecOps is not just your, I know SAST, SCA and other things, [00:13:00] but open source same applies for cloud security as well. It's so much complexity there, but for the DevSecOps audience listening to into this as well.

Cause you mentioned microservices being deployed, APIs being deployed. And I would probably say to an extent ASPM is more for modern applications, or would you say it's still because I imagine world is like a divided into monolith and Microservices,

Idan Plotnik: One important thing that will provide clarity to the audience when you assess the posture of the cloud, you have one graph when you assess the posture of your application, you have a totally different graph, different nodes, different edges. So I want to say that most of the customers that, I've worked with, they didn't know. How many APIs they have in the code and who is the code owner and what's the context of the code repo to decide if this API is risking the code or not.

So I'm just saying there is [00:14:00] a different graph for assessing the posture of your cloud versus assessing the posture of your application. And there is a different inventory for ASPM and different inventory for CSPM. In my ASPM inventory, I see all the data models. And I see the connection between a data model, which is a logical representation of data in my application.

And the connection between the data model to an API or a protobuf service or a serialization framework or a database framework, which are pure code base entities and are not related to a cloud architecture.

Ashish Rajan: I tried to emulate people who probably would be scratching their heads going, why do I care about this as well? So this is hopefully answers the question for them. But I will also wanted to add, most modern applications, the whole microservices monolith, but there's also the Lambdas, the serverless conversations, [00:15:00] which is purely code. You're just deploying applications.

There's a lot of overlap and a lot of complexity on that front as well. Depending on what kind of cloud you're using, it's worthwhile calling on application securities, quite. I would say it's been there for a while I don't know how long, but it's definitely been there for a while, 20 years, 20 plus years.

Why is there a need for an ASPM now? Cause is that, it's like one of those conversations that isn't it, shouldn't this already be solved?

Idan Plotnik: Yeah. Yeah. It's such a great question. I just want to say before I will answer this one, I want to say, what should I do with the inventory and the risk posture of your application.

Your previous question is this helps you focus across 10,000 repos, 5,000 repos on what to run these tools and processes or AppSec tools and processes, which goes back to your, this question, why do we need an ASPM now? AppSec started from a pentesting and [00:16:00] then a SAST, which tried to make the manual testing scalable and manual security testing scalable.

And then the application changed in the last 20 years so much more than cloud, I will say. Is a representation of your internal network, but in a different location application changed the application architecture technologies, languages, frameworks, open source, it changed.

So much. And this is and I can tell you when we started ASPM four years ago, everything changed from four years ago to this day. Okay. But to make a long story short, you have too many tools. You have too many manual processes. You have too many stakeholders. You have too many code repos. You have too many code components in these code repos, and you don't know the [00:17:00] short focus answer. You don't know if you're in a risk when you want to release something or not. And to be able to answer this question, if you need to release code now to your production environment, is it secured or not? You need one platform to understand your application architecture and code architecture. Augment on top of that all the findings from all the siloed tools that you just mentioned. Secrets, SCA, SAST, pentesting, API security and more and threat models and more. Make sense of all these findings on top of the code architecture.

And based on your governance, which is another complexity layer,because in one bank, there will be one risk appetite in a different gaming company you will have a different risk appetite for a different application type, and you need something to take the governance or policy as code. assess the risk [00:18:00] of the code and all the finding and then decide green or red when you want to release to production.

Ashish Rajan: I love that explanation and I'll probably put another layer to this as well to put some context for people like, isn't that what an AppSec person does? But to exactly what you put the context of 5, 000 repos and 6, 000 repos, usually we're at a very small scale, even if you look at one business unit in an enterprise, they probably work with 20 plus repositories easy, and this is I

Idan Plotnik: can say that in our ICP, like ideal customer profile, a business unit has.

More than a thousand repos, because its a large enterprise, we are scanning for one customer. We are scanning more than 300, 000 repos across five different source control manager. It's a small. AppSec team, which by the way, the KPI, the knowledge [00:19:00] and the KPI for an AppSec team is totally different from the knowledge and the KPIs for a cloud security team.

Ashish Rajan: I'm glad you brought the KPI piece as well, because at the end of the day, a security team is responsible for reducing the overall risk of the application or applications, depending on the business. Maybe before we go into this, I'm also curious. We mentioned 5,000 6,000 repos, that's very large enterprises.

So people who are sitting with, I don't know, less than 20 repos, small to medium sized businesses, less than a hundred, maybe anywhere between any less than a thousand repos, is there a need for ASPM over there? Or that's probably an overkill for them.

Idan Plotnik: The short answer is depends on if the customer is regulated or not.

Okay, if the customer has a mature AppSec program or not. But ASPM, as I said, you can look at it as modernizing your application security processes. Yeah, and to if it's a small organization, you need to bring all these siloed [00:20:00] tools within one platform and it will reduce the appsec costs and reduce the deployment complexity and will reduce the risk eventually without impacting the speed of releasing code to production. So the short answer, it depends on the maturity and the knowledge of the people. I will say that some of these smaller organization are still saying, Hey, I want to check the box with SAST. They don't care about the outcome. They just care about check the box for compliance, but as Gartner are saying, 40 percent of organizations worldwide will buy an ASPM solution by 2026.. So this is the year our team internally is calling it the year of the ASPM. What happened for CSPM three years ago or two years ago when it grow exponentially. Now we see it loud and clear from all [00:21:00] CISOs that we are talking to.

Yeah. That ASPM is a budget line and need for know what they have in the, their code bases and across the CICD pipeline and inside the code itself. Yeah to prioritize all the, I'm calling it a cacophony of alerts from all the tools and modernize the manual security testing tools, which are threat models. Risk assessments, pentesting with a proactive approach because you cannot hire more and more people to solve this problem. And this problem blocks the business from delivering faster. This is why we see a huge growth in the need of ASPM in these organizations, even the small ones.

Ashish Rajan: Yeah. And I think I love what you said as well, because if I go back to the first principle of why.

Or what a security team is supposed to do in an organization, it is to be able to assist the developers put code as much as possible in the [00:22:00] production in a safe way at the speed they want to. And usually the DevSecOps conversation is primarily focused on the fact that, hey, you should integrate into CICD pipeline.

But that use case only works if you only have one repo, one type of language being used, and potentially not a mix of say on cloud, not cloud PaaS, all of that, even in just that tiny use case of a small company, you can already see complexity. Now, if you multiply that by 5, 000, 6, 000 repos, and with, I don't know how many languages they already looking at going, okay, just to assess everything going out so that it can still release on a daily frequency or a weekly frequency, I feel like people who are listening into this, and if they're in that kind of space, they probably should try to think about, Hey, they probably should look at what do we do about this right now?

So they're probably ready for this. But the reason I bring that up is a lot of people would also be thinking, Hey, I already have my DevSecOps pipeline, my CI CD pipeline, and all of this already ready. Does that mean I'm getting rid of that? And [00:23:00] Gartner wants me to leave everything else, just use ASPM.

Is that what Gartner wants me to do?

Idan Plotnik: Before I will answer this question, which is a very interesting one, I want to say it's, that is much more complex than what you described. Why? Because in most cases, you don't want to even catch these Okay risks in the CICD pipeline in here, like the build and deploy pipeline.

You want to catch these things earlier. You want to catch these things when you commit code to your source control manager at the commit or at the pull request. Right now, there is a huge movement from the CICD pipeline and integrating these tools into the pull request into the commit phase.

Even in our mature customers, they're using Apiiro to assess the risk at the user story level. Okay, when you request a feature, we can assess the risk there by [00:24:00] scanning the text and identifying the intent at the user story. So let, I want to say that, and I can, again, this is only my view, but I see a lot of customers.

We, as a team, we see a movement from taking these tools because they are slowing down and it takes hours to scan a build pipeline hours, while in the pull request, it's much faster. It's a five minute window. Which is the SLA. And then you get a faster feedback while the developer is still in the context of the risk and you help him in the pull request to know who you should talk to, what are the violations for the, based on the organization policy and governance and what you need to, or how you need to fix it, this is one thing to your question, if ASPM will replace the entire [00:25:00] pipeline? No, absolutely not. Okay. ASPM should be deep and open platform. When I say deep, you need to connect to the code base. You need to scan. The code base, not only to identify risks, you need to map all the components that you have and the relationship between them.

And you can call it finally based on cycle on the X, you can call it XBOM and extended SBOM, not only all the open source dependencies that you have. All the open source dependencies, all the RESTful APIs, all the serverless functions, all the data models, the PII data, and the relationship between them.

And then you need to be open. What does it mean? You need to be able to connect to any source control manager, any CICD pipeline, any SAST tool, any SCA tool, any secret scanning tool, and so on and so forth. And you need [00:26:00] to be able to connect to what the customer already Implemented in their environment and should not replace that.

Ashish Rajan: I love it. And I think it goes back to what we were saying about the complexity of multiple languages, multiple platforms. If they're not open and not able to talk to each other, then it's pointless at that point. We're still back in the same dark ages for lack of a better word. So if it's not a replacement of my current pipeline, and as much as we spoke about CSPMs and SAST and SCA , you've been mentioning API security as well.

Now what's the role of, and I guess it clearly fits in the ASPM space. Cause you've called it multiple times for people who are still going, is this my cloud API? Is this my application API? What API security are we talking? Cause I bet you this so many people don't even pentest their APIs just in general, but I'm curious to hear your answer.

When you say API security, what are you referring to?

Idan Plotnik: The application space, application development is a complex domain. To make it simple, I'm talking about [00:27:00] API security testing. So ability to test the RESTful serverless protobuf APIs that you developed in your code in your custom application and put guardrails early in the development lifecycle.

So it goes back to your maturity level, and if you understand. That a restful API is an attack vector that attackers are using when it's getting into runtime and stealing data bypassing authentication and you have OWASP Top 10 for API security need to scan the code and it's not yet another SAST solution.

It's the same technology of scanning code. It's a different implementation on top of that. Yeah, so I'm talking about inventory. All the APIs that you have in your code bases understand the security controls your developers implement. [00:28:00] Understand the data classification that these API exposes while you scan the code and three understand the coverage off your testing tools and processes that are running on your APIs before you deploy them to the cloud. Now this is part of a deep ASPM not a shallow ASPM what we called, ASOC that can aggregate all the alerts and doesn't understand what to do with them or, sort them or by CVSS score temp.

So a deep ASPM actually understand the code and your APIs. And if you take it one step further, the ASPM connects to your runtime API security solutions. Or WAF or API gateway or advanced API security solutions and connect the dots and say, Oh, great. I see that this alert for this API in [00:29:00] runtime is connected to this code repo to this API that Ashish developed three months ago and deployed it a week ago. Okay. And then you can really prove business outcome by reducing the prioritization time and reducing the MTTR, the mean time to remediation. And you can finally in AppSec define SLA for fixing an issue coming from runtime or coming from the default, like from right to left, from runtime to the code or from the code to runtime.

And this is the entire essence of a deep ASPM.

Ashish Rajan: I love the call out that API is still very misunderstood for a large extent, and it still needs, we've said everything API these days. So it's almost like confusing because a lot of people who would be working on the CDK, which is the cloud development kit that most cloud service provider provide, they're also written in code like Python, Java, all [00:30:00] of that as well.

So this kind of expands a lot more because it could be API called for that as well. I wonder if there's a regulatory requirement that requires the ASPM to to what you said, people are maybe already looking for this and there was never a platform that was available or labeled by Gartner for, hey, you can use this for this.

Is there like a regulatory requirement for this as well? Yeah

Idan Plotnik: it's such an important question, Ashish and I want to invest a few minutes on that. So I will say now in categories, PCI v4 explicitly saying it, and I will give some example, CIS, SLSA and NIIST they're not explicitly saying ASPM, but in a PCI V4 in section 6. 3. 2, they explicitly saying that you need an inventory of all your custom software. third party software components, the relationship between them to be able to assess the risk of a [00:31:00] software that you develop and section 6. 2. 3 B explicitly saying that you need to provide evidence of significant changes and provide an evidence that you're running these AppSec tools and processes across all of them say same as section 6. 5 in PCI version 4 and CIS and SLSA and NIST are saying the same thing on your custom code, open source code, the security controls on your source control manager and on your CICD pipeline. So finally, and we are saying it. For three plus years, you cannot look at your software supply chain as a silo and assess the risk there without understanding the code.

You cannot secure your pipeline because you get tons off pipeline misconfiguration, [00:32:00] but who cares? This pipeline does not build high business impact application with PII data or an API that exposed this PII data. Think about physical pipe. Okay. That provide water to a country without controlling the water and if you have something inside these waters, you cannot actually secure the water inside these pipelines. This is how we think about it. You need to look at it as a triangle. As Code, secure your code, the application code, open source code, custom scripts.

You need to secure your source control managers and CICD pipeline in one platform. And this is exactly what PCI version 4, CIS, NIST, and SLSA are saying loud and clear.

Ashish Rajan: Awesome. And are there SCC rule as well for this,

Idan Plotnik: There are SCC evidence that requires, and, but the SCC is basically taking it from [00:33:00] NIST and the secure software development framework.

So it's the same, and there is one important initiative by CISA that I'm sure everyone will hear about it because CISA just released a request for comments in December 18. This was the deadline for the secure software attestation for and finally from a practitioner discussion it goes to the COO and the CEO accountability. They need to sign on the software that they produce, same as they need to sign on their financial reports. Oh, which is amazing for us as an industry. Finally, it's not the AppSec engineer that takes the responsibility or the accountability or even the CISO.

Yeah, it's the CEO and the COO or the COO that needs to sign on a secure [00:34:00] software attestation form and take accountability for the security of the software and software supply chain. of a producer, of a software producer company. And nowadays we know that even banks are software companies.

A

Ashish Rajan: lot of them are examples as well.

I also wonder that your point on the CISO thing as well, a lot of people, it's that time of the year where a lot of people are already thinking about what to add on the cyber security program. How should they look at it? They may already have components for AppSec and cloud security and APS security in there as well.

How would you suggest, because I think we started the conversation with the whole KPIs have changed for what used to be the traditional application world. How would you suggest they measure and manage security risk for their modern cloud build applications?

Idan Plotnik: We are actually working on an ASPM Operationalization model that will provide all the KPIs that our customers are measuring us [00:35:00] for assessing their risks.

There are nine. The key is how much time you spend on a manual risk assessment questionnaire and the accuracy versus how the ASPM automates this process. It's the total finding that you have today or findings, I'm saying vulnerabilities, weaknesses, and risky changes versus the prioritization funnel after you assess these in an automatic way, which is connected to the first KPI and the last one is the actually MTTR before you deploy an ASPM and MTTR after you deploy an ASPM You can measure it. It's a simple way of measuring before and after.

Ashish Rajan: Actually to level the playing field, you probably should also say what MTTR is as well. Cause some of you may not even know what that is.

Idan Plotnik: So MTTR is the mean time to remediation and how much time [00:36:00] it takes you.

Basically large enterprises are measuring it based on the business impact of the application. Yeah, the data classification inside and saying for critical risk for a high business impact application, you need to fix a risk in one day. If it's high, it's three days. If it's medium, it can be a week or two weeks and depends on the organization.

So this is meantime to remediation versus the SLA and the SLA is driven from the business impact of the application. The last thing that I want to say, which is tied to the first KPI is explicitly written in the ASPM report. You need to modernize your manual risk assessment process, pentesting, threat models, and to be able to do that, you need to automatically identify what are the material or [00:37:00] the risky changes, which are totally different from vulnerabilities and weaknesses.

Just to give you an example, a risky change can say you added a new database framework and no one reviewed it, you added serialization framework that store this sensitive data in a storage bucket or in a database, you need to review and run a pentest based on that and you cannot. And it's the velocity of changes grows exponentially in modern applications, so you need something that will automatically identify these risky changes and trigger the manual process for review. So an outcome of a vulnerability of a risky vulnerability is remediation, like prioritization and remediation outcome of a risky change is prioritization and review. , so these are different. Outcomes.

Ashish Rajan: It connects with the audience as well.

Now, that's most of the technical questions I had. I have general questions for you as well. So that's so people get to know you a bit more. [00:38:00] The first one being, what is something that you're proud of, but it's not on your social media?

Idan Plotnik: Ooh, it's a tricky question. There is something that I cannot say because we are going to release it very soon.

Ashish Rajan: And

Idan Plotnik: I'm very proud of it, but I think to try to generalize it, it's how and we didn't do a good job at that and we are going to change it.

It's how customers listen from customers, not from me. not from our marketing team, not from, analysts see hear directly from customers. Yeah. What are the business outcomes or what are the opposite goals that they managed to achieve with an ASPM and what are the business outcomes that eventually they managed to get from using it?

And I am very proud of, and this is not in social media, and I'm very proud to hear from CISOs and from. VP director or even [00:39:00] practitioners around appsec.

Ashish Rajan: Awesome. And my final question is more, more directed at you yourself. What is your favorite cuisine or restaurant that you can share with us? I don't know. I love good steaks. Steak and fries or just steak by itself? Just steaks.

Idan Plotnik: Oh, nice. I have a restaurant in Israel that I really which called meat bar.

Ashish Rajan: I guess it's all meat.

Idan Plotnik: I'm in Israel and not traveling. I really like this one.

Ashish Rajan: So I'm definitely going to look that up and check it out as well. The next time I'm in Israel.

Idan Plotnik: But I invite you, I will take you there when you,

Ashish Rajan: I appreciate that. I'll take you up on that as well. By the way, thank you so much for coming on the show, man.

I really appreciate this. Where can people find you on the internet and we can learn more about Apiiro as well.

Idan Plotnik: Just LinkedIn, you can ping me you can follow Apiiro or just getting to our website, Apiiro com. Find us there and would love to show you more on the deep ASPM space.

Ashish Rajan: Awesome. I'll put that in the show notes as well. But thank you so much for your time, man. And I look forward to having you again on the [00:40:00] ASPM conversation as it evolves. And 2026 is not far. So I'm sure we'll be having a lot more conversation, man. Thank you very much Ashish. Thanks everyone. And we'll see you next episode.

Thank you.

‍