Idan Plotnik: [00:00:00] Every organization, and I'm asking every CISO the same question. How many APIs do you have in the code? How many Gen AI technologies do you have in the code? Where across your 10, 000 repos, where do you have PII data? They don't know this answer, but they do know how many containers they have in the cloud or how many endpoints because they build an inventory.

But in the AppSec program, They didn't build an inventory. Why? This is the fundamental concept in cyber security. If you don't know what you have, how you can protect and secure it.

Ashish Rajan: If you are a company with about 700 to 15,000 , 20,000 developers, this is an episode for you. We're talking about ASPM

I know we have another acronym in this world of cloud and AI that we're walking in, but this is important because after a certain point, you'll realize if you have that many developers, you have about let's just say an average 3000 commits per week per day happening and the number of changes that happen and how dynamically they're happening.

It definitely begs the question for how are we keeping tab on the [00:01:00] APIs? If you don't have an inventory of the application you're looking at, how are you even securing them? So this episode is inspired by the ASPM category that Gartner had announced. And now there's a lot of people who are in the space.

And Idan from Apiiro. And let me tell you it was a passionate conversation and we spoke about who is the ASPM for? As a leader who is trying to make a call on whether you need an ASPM or not what kind of things that you should be looking out for in the ASPM world. After all you've invested so much money in all the security products you bought do you really want to take any of them out which is going to take weeks or months.

Being mindful of that while still making sure that you're able to increase the number of commits and productivity of your developers while reducing the number of vulnerabilities being introduced in your production as well. If you know someone who's working on that ASPM space in that large enterprise, this is the episode for them.

And if you're not in that large enterprise, This is a good episode for you to at least get an understanding for what it would look like as you move into this space of there's a lot of changes happening on a daily basis and how do you deal with security on that scale. All that and a lot more in this episode of Cloud Security Podcast.

I hope you enjoy this conversation with Idan and [00:02:00] if you're here for a second or third time, I would really appreciate if you're watching this on YouTube, give us a subscribe or if you're listening on iTunes or Spotify, give us a five star rating and give us a follow as well. It does help us spread the word of the cloud security work we're doing here and giving you information that has been helping you do your job better and make the Intelligent decisions for the program that you're building for your organization.

I hope you enjoy this conversation with Idan, and I'll see you next one. Peace. Welcome to Cloud Security Podcast. Recording now. Welcome, Idan. Thank you for coming on the show.

Thank you for having me.

Oh it's a pleasure, man. For people who may not have met you or heard about you yet, Can you tell us a bit about yourself and cyber security career of yours?

Idan Plotnik: So I am now 23 years in the cyber security.

Ashish Rajan: You look 23 as yourself by the way.

Idan Plotnik: I started my career at the IDF in a cyber security unit as an engineer. I was there around five years. Then I become a practitioner or doing pen tests and security code review and risk assessment around two years. Then I founded my own consulting services company.

Ashish Rajan: All [00:03:00] right.

Idan Plotnik: Sold it after a few years, started the startup. Through one of the pentests, I found something interesting and I did a research. I wrote a patent based on this pentest that I've done. And I found that the company, we were the pioneers in the UEBA space. It's User and Entity Behavior Analytics.

It does not exist anymore. It's part of XDR now. Okay, and we sold the company to Microsoft in 2015. And at Microsoft, I was the GM for Software Engineering for Defender for Identity. And I felt the pain or I would say the challenge of embedding risk management and application security processes and tools into the development lifecycle.

Ashish Rajan: Yeah.

Idan Plotnik: So instead of moving faster, we moved slower, and it impacted our business. Then this was the catalyst to why we started up here all four years ago.

Ashish Rajan: You guys are in that ASPM space. So in 2024, What is ASPM? How would you describe it? People probably are still not familiar with that acronym.

Idan Plotnik: So [00:04:00] application security posture management is actually inventory everything that you have in your codebases and across the development lifecycle.

When you commit code, What is in this code, where it's being built through which pipeline is going to be deployed to the cloud and where it's running. This is ASPM. Now, visibility on top of that, you have prioritization and remediation with a risk based approach, not based on CVSS score or EPSS, but actually understanding the environmental scoring of where this vulnerability is running.

What's the business impact of the application? And based on that, say you have an impact on the business or not, this is the second layer of ASPM. And the third layer is to actually manage the governance process, prevent the developers from deploying risks to the cloud and measure saying, I want to [00:05:00] see that my development velocity goes up, number of pull requests, merged number of builds while the risk is going down.

Ashish Rajan: Yeah.

Idan Plotnik: Before releasing to the cloud.

Ashish Rajan: Interesting. Yeah. It should be inversely proportional. Sounds like something that only a certain level of organization, is ASPM for everyone, every size of organization?

Idan Plotnik: No. We see that organizations that has their own tools and they bombarded with vulnerabilities that they need the prioritization or the large organization that needs compliance and governance throughout their development lifecycle.

So the small companies, they're not going to use an ASPM, Okay . Because they have 50 developers, 100 developers, so they can use commodity tools, open source tools, and the amount of vulnerabilities that they're getting is small amount. Yeah. And the developers are still there. It will not affect the development velocity.

When you have thousand [00:06:00] developers, let's say above 500. The largest customer that we have with 17, 000 software engineers. Okay, so this is the range where, you know, between 500 to 20, 000. This is where you need an ASPM. Now, in between, you have the ones that will, want to use an ASPM with the built in scanners or solutions like SAS, DAST, SCA, secret scannings, API security testing and code and stuff.

And the large ones, they already invested in these scanners.

Ashish Rajan: Yeah, that's right.

Idan Plotnik: Yeah. So they want context, risk based context to prioritize, remediate and prevent developers from delivering risks to production

Ashish Rajan: Interesting because I was going to say that if the scale of people who can use ASPM is between that 500 to 17, 000, like that's a big leap.

And in most of those organizations, people already have a SAST tool, a DAST [00:07:00] tool, there's already DevSecOps program, everything else is already, there's a AppSec person, cloud person, everyone's already there. To your point about the three buckets that you referred to with ASPM with the visibility. Then there's the compliance governance market as well, and then in terms of having a risk posture.

For people who are cyber security leaders and are also listening to this conversation, in 2024, what would you say if they are in that range of that many developers, what should they include in their cyber security program?

Idan Plotnik: I don't think that it's something that they didn't see.

I I think that what I would recommend them for these that already have the mature program with scanning tools. Is to have a layer, which is the ASPM, the layer of context on top of that,

Ashish Rajan: right?

Idan Plotnik: And the context can be from the source code, from the code itself. It can be from the development environment, and it can be from all these controls that you put in place in the cloud, like your CSPM and WAF [00:08:00] and other stuff connected to the code. And I think, you know what, I will take one step back and I will say every organization and I'm asking every CISO the same question and they don't know. How many APIs do you have in the code? How many gen AI technologies do you have in the code?

Where, across your 10, 000 repos, where do you have PII data? They don't know this answer, but they do know how many containers they have in the cloud or how many endpoints because they build an inventory. But in the AppSec program, they didn't build an inventory. Why? This is the fundamental concept in cybersecurity.

If you don't know what you have, how you can protect and secure it. Yeah. I would say that this organization needs to start with inventory across their AppSec program. What they have inside the code and where this code is being built and delivered and eventually running in the cloud. You don't need to [00:09:00] protect it, but you need to know the basic questions.

Ashish Rajan: Yeah.

Idan Plotnik: What my developers are doing, how many APIs they're adding to my code every day, which Gen AI technologies they're using in the code base, where this data is written into logs, database, which databases in my code my developers are using, they don't know that they know it, some of it from the cloud, but it's too late when it goes into runtime.

You want to prevent, this is the KPI of AppSec. The number of risks should go down before you deliver to the cloud. This is the KPI.

Ashish Rajan: Yeah, that's right. Yeah. Cause cost is lower. Exactly.

Idan Plotnik: And if you're not doing it, you're not doing your job well. And if you don't know what you have, how can you get the risks?

Now I can prove it in the data. I don't have my laptop here, but I can show you that when you have thousand developers, you have 3000 pull requests a day or, between a day and a week. Yeah. 3000 [00:10:00] pull requests. You know how much new changes are getting into the code which means new APIs, new technologies, new dependencies.

It's complex. Your attack surface is literally changing every day and you don't know it and you're waiting until the CSPM will detect all these things. Why? You need an ASPM to understand the attack surface, understand the changes, understand what you have, build this inventory. And based on the data in the inventory, you can define guardrails, which are not based on CVSS . It's great, but it's not enough. It's based on a lot of data that you gather together and you stop the developers only on what will impact the business. And I do want to say that there is an element of deep knowledge of the code and there is an element of openness because these organizations, they [00:11:00] already invested a lot of time and money and effort in their programs.

You cannot come and say, Hey, remove now your SCA and secrets and SAST tool. You cannot do that. You need to come with the platform that says, Great. You already invested in these tools. Let me pull them in. Exactly.

Ashish Rajan: Yeah. Yeah. Let

Idan Plotnik: me enrich them. Let me Contextualize the finding. Let me deduplicate the findings.

Ashish Rajan: Yeah.

Idan Plotnik: Let me understand if this is used in your code or not If this is exposed if it's involved sensitive data.

Ashish Rajan: Also to your point because my first thought was gonna be that exactly what you said as a CISO You I've already bought into the SCA, SAST, as well as the DAST world.

Everywhere, like all of this, including a CSPM, probably two CSPM depending on how big they are. A lot of challenges has been the fact that these are all silos in a lot of companies. But you keep referring to AppSec teams as well. Is that because it's an AppSec challenge or is it more of a because I know who's supposed to be doing this, I guess in your mind.

Idan Plotnik: Before I will answer, you [00:12:00] said something super important. You said silo. What we see is that when you get an alert from a SAST, an alert from an SCA, an alert from secret, Yeah, they are connected and when they are connected into a toxic combination, This might take the impact and the likelihood higher in, in the risk assessment.

Yeah. So these tools, they don't see each other. So this is one of the core capabilities of an ASPM, a deep ASPM, is to understand the usage of features. these vulnerabilities or alerts together. But now this to your question, it's a shared responsibility. AppSec needs to manage the process. They understand governance.

They understand risk. They understand security. Developers don't understand these words. Okay. So you need a platform to enable them to codify or define their risk In a very [00:13:00] simple way, and then translate that into a developer language in the development tool chain. Because the developers own the remediation of the process.

They need to fix it because they know their code. The AppSec cannot fix the risk, okay? They can say when you pass the risk appetite or threshold, and then prevent you and provide you the guidance. Of how to fix it. Yeah, but the developers own the remediation. That's right So the app sec owns the governance and the prioritization The developers own the remediation and they don't want to yet another tool.

No way. So if you want to be a successful ASPM, you need to be open. Open means to connect to your pull request and connect to your JIRA or Slack or Teams, whatever the developers are using.

Ashish Rajan: Yeah, or even SCA and SAST tool as well. Yeah, of course.

Idan Plotnik: This goes without saying. Yeah. [00:14:00] The developers doesn't care about SCA.

Ashish Rajan: Yeah, they don't. Yeah, I love the example off the fact that they need to be open to be , okay to have connect to a PR, connect to a Slack, connect to SCA, connect to SAST because, or to build, connect, to build,

Idan Plotnik: or even trigger a process when you just do a GIT push to your SCM. Yeah. Source control manager.

Yeah. Which is before you open the PR. Yeah. Which is earlier. Pretty much.

Ashish Rajan: Yeah. I love this because we started the conversation with openness, deep visibility. And the depth part is interesting as well, because a lot of AppSec people, CloudSec people at the moment are siloed and there is this whole notion that hey, AppSec and CloudSec is going to combine at some point.

Do you feel ASPM is that beginning of where now all of that is being brought in together?

Idan Plotnik: I would say no. Okay. It will connect everything together, but it will not unify the personas. The persona of the cloud security. They don't understand code. They don't [00:15:00] understand application architecture.

They do understand cloud architecture. Yeah. Yeah, if you will ask them to design end-to-end, microservice architecture and stuff like that. And which firewalls do I need and which encryption in the cloud do I need? They can do that. Yeah. But if you will ask them how to structure this code module, that will be a scalable with ingesting this amount of data in Java as well.

In Java. Exactly. Yeah. Yeah. Exactly. It's a totally different knowledge that they have. It's not only that, it's also the KPIs. The KPIs of cloud security is different than the KPIs of AppSec. And what I learned throughout my career is that it's hard to sell to a different persona. You can have the same technology.

Ashish Rajan: Yeah.

Idan Plotnik: But to sell to a different persona with a different language, with a different. KPIs with different sales process it's hard. [00:16:00] So this is why I think maybe ASPM will bring the data from runtime and from cloud to the left side. Yeah. But to make a better decisions throughout the development life cycle, because the developers own the remediation, you will use the CSPM context to say, Hey, this API that you have a vulnerability.

Now it's exposed to the Internet. You know that through the CSPM. But who is the code owner? You need it from a deep ASPM that actually scans the code and say you're the code owner of this API, which is a huge problem, by the way, in AppSec, maybe in small organizations where the budget is tight and you will have one person on CloudSec and AppSec.

Yes, and he will be maybe more as a generalist and he will know what to pass to developers or what to pass to DevOps.

Ashish Rajan: Yeah,

Idan Plotnik: but in the large enterprises, I don't think that it will happen in the next, you know what, I don't want to say [00:17:00] never. Okay, so in the next three to five years. Yeah. I don't think that in large enterprises, this is something that will happen.

And by the way, it's also a compliance issue because you need the segregation of duties. You need segregation of duties for someone that owned, take accountability and responsibility , do a secure release and it's not the accountability and the responsibility of the cloud they need to make sure that you are not being breached and that you have uptime which AppSec doesn't care about that

Ashish Rajan: Yeah, okay point is the exact opposite thing that they would not even know how to do it Yeah, so there is that gap as well and I agree with large enterprises who have been doing this for years, it didn't even have an on premise.

If you think about it, leave the cloud conversation aside, one would have thought if all of our goals are unanimous in we need to protect applications and we have had sysadmins, network security people for so long. Yeah. But that never merged into AppSec. It's always a developer who [00:18:00] turns into an AppSec person because to your point about the knowledge of the code, the software architecture, everything that goes behind it.

Another thing that is adding on to these days is the whole supply chain and XBOM or XBOM as you guys call it. What is XBOM and what's the context of supply chain and XBOM that you're probably highlighting?

Idan Plotnik: Sure. Maybe I'm supposed to say to the beginning of the conversation, but we developed a technology It's a patent technology that's called DCA, Deep Code Analysis.

This is the technology. Now, what this technology is doing is scanning code repo throughout the history, because, for example, SAST scans a file, snapshot. Yeah. Yeah. What we did, we took deep scanning across the history and translating code into entities. Entities actually assembled an application, APIs, data models, authentication framework, Gen AI frameworks, and more, and connect them on a graph.

This is the technology. SBOM [00:19:00] came to life many years ago. Okay. Software Bill of Materials, saying show me a list of all your open source dependencies. Great. But it's not enough. This does not represent all the ingredients of your application. It's you will tell me this sandwich, okay, it's assembled from, I don't know, whatever, one ingredient?

No, it's multiple ingredients, okay? So what we did, we called it an extended SBOM. Okay. Of saying it's not a list, it's a graph. First and foremost, it's a graph. And dynamic. It's dynamic, but it's also connected to each other. So if you have an API, this API using open source dependency, they're connected.

Yeah. And this API exposed PII data, which is another node it's connected. So what we are seeing, it's a graph of all these components that actually assembled your application attack surface. Yeah. And this is what we called an extended SBOM. [00:20:00] And when you connect us to the source control manager, you can export an SBOM from a Apiiro.

Okay. But we also offered you to export an XBOM because this will represent your application attack surface and it will help your pentesters to understand your application better. It will help you understand the risk better. This is the context that we're creating to assess the risk. It will help you put guardrails in a better way.

And this is the difference between a list of open source dependencies versus a graph of everything is connected and it's not only open source dependencies.

Ashish Rajan: It does. Yeah, I think the dynamic nature of it definitely makes more sense as well. And it changes

Idan Plotnik: Yeah. Like literally every day.

Ashish Rajan: Yeah, if you're having 3000 commits being made on a daily, weekly basis, it's already changing by the time you even made it available on the internet.

Those are most of the technical questions I had for you. I've got three fun questions. I think you've done this so far, [00:21:00] but I'm going to curious there if your answer is a bit different. First one being, what do you spend most time on when you're not working on solving the ASPM challenges of the world?

Idan Plotnik: I have two things in life, family and work. That's it. That's it. That's it. That's all you can do. I used to go surfing. Oh, okay. Nice. Kite surfing, wave surfing. Oh, wow. I literally, I don't remember when the last time I did it, like I have my two amazing kids and wife and a dog that I don't see them a lot.

Okay. Yeah. I I don't see them a lot because. Work and building a company. It's a big commitment. Okay, but that's it this is where I spend my time like with the family or at work very well said and I will tell you a secret Yeah, my wife will not hear when I'm with my family. I think about work Yeah,

Ashish Rajan: ASPM is like what like nothing Second question.

What is something that you're [00:22:00] proud of that is not on your social media. I am proud that

Idan Plotnik: It's not publicly yet. Very proud on the last few huge deals that , we did at Appiro. Huge logos that I don't think that a company or a startup in our size can go and close these deals. And I'm so proud of the team because it's a team.

Team effort.

Ashish Rajan: Yeah.

Idan Plotnik: Across the board, product, engineering, marketing, sales, partnerships. It's like you see these things connected together. Yeah. Into a result. Yeah. And it's not publicly available yet.

Ashish Rajan: One day, one day. Hopefully very soon. Hopefully. Final question. What is your favorite cuisine or restaurant that you can share?

Idan Plotnik: I think I told you that in our last interview. I like meat. All forms. And in Israel there is an amazing restaurant. When you will come to Israel. [00:23:00] Tel Aviv. Not now. Okay.

But I will take you to a restaurant in Herzliya called Meat Bar. Oh, it's called Meat Bar as well. Meat Bar. High end Meat restaurant.

Ashish Rajan: Yeah. Okay. Amazing. That's most of the question I had. How can people find out more about Apiiro and what you're doing and where can they connect with you as well about all of this?

Idan Plotnik: So of course, LinkedIn, but also Apiiro. com, A P I I R O com. We just launched a a partner. An integration program through our openness ethos at Apiiro

Ashish Rajan: yeah.

Idan Plotnik: So it's called Shine. Okay. Our partners can shine with us and with our deepness and the inventory. Yeah. Nice. So everyone can shine together.

Yeah. So you can go and check it out online. Yeah. That's it. I'll put that link in there as well. But now, dude, thanks for coming on the

Ashish Rajan: show. I appreciate that. finally doing it in person as well I appreciate this, Thank you so much. Thank you for listening or watching this episode of cloud security podcast. We [00:24:00] have been running for the past five years, so I'm sure we haven't covered everything cloud security yet.

And if there's a particular cloud security topic that we can cover for you in an interview format on cloud security podcast, or make a training video on tutorials on cloud security bootcamp, definitely reach out to us on info at cloudsecuritypodcast. tv. By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister AI Cybersecurity Podcast, which I run with former CSO of Robinhood, Caleb Sima, where we talk about everything AI and cybersecurity.

How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of ChatGPT, and everything else continues. If you have any other suggestions, definitely drop them on info at CloudSecurityPodcast. tv. I'll drop that in the description and the show notes as well so you can reach out to us easily.

Otherwise, I will see you in the next episode. Peace.

‍