Integrating Application and Software Supply Chain Security with Apiiro’s Idan Plotnik

This is Textron tv. Hey guys, thanks for the throw. We're here with ya, Don Plotnick, who's CEO for api, and we're talking about the relationship between application security and then the security of our software supply chains, which, uh, are slightly different, but should probably be addressed in some sort of cohesive fashion.

Don, welcome Michelle. Thank you very much. Thank you for having me on the show.

Michael, What's going on here these days? I think we went from everybody ignoring the security of their software supply chain on the one hand, and then treating application security almost like they're red headed stepchild in the second hand to now we're all kind of talking about it, but sometimes I feel like maybe we're talking past each other. So from your perspective, what exactly is going on here?

Yeah, um, I think this is a very, very complex topic that I will try to simplify it first. Um, there are, you know, attackers out there that are attacking our CICD pipelines and source control manager, where we store our code, but they also attack our applications, which is, you know, assembled from code and other artifacts. Um, so suddenly, you know, a new attack, uh, were born in the wild.

So there are so many companies that are saying, Hey, we need a bandaid for this specific attack vector. The problem is, no, you cannot do that because then you will get noise and more alerts that you don't have the right context to fix them. So what we are trying to say is that you first need to un need to understand your software architecture without understanding your software architecture.

And I mean by saying software archite architecture, architecture, I mean, understand what is the programming languages? How many microservices? Where do you have sensitive data in the code?

Where do you have APIs in the code? What actually stores the code? And what are the permissions the developers has to access this code?

And then what builds the code? And then what delivers the code to our customers or software to our customers? Only when you have a deep understanding of your software architecture, only then you can identify these types of advanced attacks.

You can prioritize them based on your business impact and fix them or reduce the mean type two remediation of these types of attacks. Because think about this for a second. If I'm an attacker and I breached your CICD pipeline, you will tell me, Hey Don, it's a, it's a very complicated attack and I need to prevent it and block it.

But I would say, no, it was a test pipeline. There is no core intellectual property there. So why you need to invest your time on fixing these types of risks while you have other critical business impact risks that you need to handle.

And you don't have a lot of manpower to do that. And same goes for open source dependencies because they are part of the supply chain. If you are using an open source package with the vulnerability, but it's not in an application that ha it's a high business impact application or it's in a test environment or other things that, or other context that you need together to decide if you need to prioritize this now or later on.

Does this make sense? Mm-Hmm. How targeted are the attacks?

Are the bad guys getting into the supply chain and looking specifically for applications that they can put malware in that is externally facing? Or they just kinda basically dropping malware everywhere and open something from their perspective? Good happens.

They're shooting all over the place and they're, uh, trying or to hope that one of them will fall or will be used in a high business impact application that is internet facing. Um, the advanced targeted attacks, uh, like what we saw on SolarWinds or other, uh, uh, zero days are took more time and to assess and do the reconnaissance saying, Hey, SolarWinds had, uh, thousands of customers. If I will breach one CICD pipeline, then I can impact thousands of environments.

This, this type of attack takes time and it's not the common, um, attacks that we see in them wide. Okay? Um, I I do want to say that we are analyzing all GitHub on a daily basis across all the material changes that happens there.

We see a lot of malwares, malwares, I mean not a, a package with a CVE, okay? That like it's a known vulnerability in NVD or any other vulnerability databases. We see a lot of packages with unknown vulnerabilities with malwares, and eventually we alert them to our customers, but we alert them because not across all of the users of these open source packages with malware only because we automatically, and in a second, I will tell you what we developed in app Pure.

We automatically assess the code ripple, if it's a business impact, high business impact, medium or low business impact. If this open source dependency is actually reachable or not, is it deployed to production? And is if it's, uh, uh, internet facing application, we gather all this information to say, okay, you have 10,000 alerts, but only 1% of them are pretty critical to to your business.

This is what I mean by assessing your software architecture before opening tickets and opening, uh, pull request for a remediation and stuff like that and bombard your software development teams with a lot of work that will not impact the business. Does this make sense? Mm-Hmm.

I, I understand what you're saying. I think a lot of organizations are also a little overwhelmed about where to get started. 'cause sometimes they're like, well, should I just apply zero trust principles to locking down access for the developers and that'll take care of that attack vector?

Or do I need to do something more ambitious? Or do I need to replace my entire CICD pipeline with something that is a more secure DevSecOps pipe pilot? So where, you know, what are you seeing folks doing Secure by design, uh, pipelines?

Uh, I, I would say that this is the biggest problem I think in the, in the software development industry. And you, you want to make sure that you are secure by design without impacting the development velocity. Because if I am a CIO, my KPI is, or, and, you know, engineering leader, my KPI is to release more and more value to our customers in high velocity, high quality.

And this is what my focus is because high development velocity means high business growth. It's a direct correlation between the amount of features that you deliver to your customers and your business growth. Uh, because they are paying for new capabilities and new business value.

Now, security comes into play and exactly touches on what, what you, uh, uh, alluded a second ago is that you need to put more controls, more gis, more, um, um, scannings and these types of actions from the security side blocks the developers and bombard them with so much noise from all these point solutions siloed, uh, scanners. One scanner for, uh, scanning your open source dependencies and one scanner for scanning your CICD pipeline and another scanner to scan your source control manager and another scanner to scan your applicative code and secreting code. And these siloed tools do not understand your software architecture.

They generate hundreds of thousands of alerts and then the security team needs to do, or the application security team needs to, uh, uh, do a lot of manual triage work to say, okay, you have hundreds of thousands of alerts, but Mr. Developer, please only fix these types of risks that are mattered to your business. And this is a hard job.

The application security engineers, they are, they need to have a lot of deep understanding of software development processes. They need to understand code. They, they're, it's a different set of skills than, you know, the cloud security teams that identify things in runtime.

So to make a long story short, you cannot create these hundreds of thousands of noisy alerts for the development and pass them to the development team to ps. And how do you do that? One, you have one platform now it called, it calls, um, A-A-S-P-M application security, posture management platform that deeply understand your software architecture, your software development lifecycle, and how do you design software, how you develop software, and how you deliver software.

And when you have this context, then you can minimize the noise and make sure that developer invest only 5% of you know of their backlog or, or, you know, sprints on security tasks versus developing features in the 95%, the rest of the 95% of their time. Who's in charge of this then? Because some folks would say it's an extension of a DevSecOps workflow and therefore it belongs to the DevOps team.

And other folks say, well, actually it's the cybersecurity team that needs to manage this. 'cause it's one more use case where they need to secure the environment. And I think sometimes there's this assumption that both sides are doing it and then nobody does anything.

I totally agree with you. Uh, and it's even more complex with that because you have the developers that they are the only ones that has the knowledge and the capability to fix code. You have the DevOps that has the knowledge and the capability to fix permissions in the source control manager or CI ICD pipelines.

And you have the application security engineer that cannot fix anything, but they are in charge under the cso, um, in charge of implementing the scanning tools and prioritizing the outcome from the scanning tools. So you have three different personas, developer under the CIO AppSec engineers under the CISO and the DevOps that are under the software engineering side. So A SPM aims to solve this language or, you know, they have different language and, and def different, uh, uh, uh, knowledge and different processes.

And A SPM is now aimed to solve this or bridge the gap between developers, application security engineers, and DevOps people in one platform where you connect to their existing investments because they will not change their source control manager and they will not change their CICD pipeline and they will not change their, uh, technologies and frameworks and languages that they're developing the software and they will not change their scanning tools. So you need to connect all these together and say, if I'm talking to a developer, this is the lingo. If I'm talking to an AppSec engineer, this is what they need to do.

And if I'm talking to DevOps, this is what I am showing them in a dedicated dashboard, in a dedicated workflows. And this is how we bridge the gap between these three personas. Um, You cannot walk down the street of course these days without everybody talking about AI to one degree or another.

Might AI in this use case save us from ourselves here? So, Uh, I think we need to double click on AI and it, you can do amazing things with ai, even in application security and software supply chain security. You can use that for detection, prioritization, uh, prevention and automation.

And this is what we're, we built, um, a technology called DCA deep Code analysis. Think about we take all your code and we, you know, I don't know how much like or if you are able to read code, but if not, this is exactly what we're doing. We're taking the code, passing it through the DCA, the deep code analysis, which uses ai, and then we visualize your software architecture and we translate that into components.

For example, we take code and then we say, Michael, you have 5,000 APIs in this code base and these APIs are exposing this type of AP of PII. And you cannot do that without the help of ai. So just to summarize, yes, we are also using AI to make the life of developers, application security engineers and DevOps more efficient.

Just again, taking code, taking pipelines, taking configurations and saying in a simple way why it matters. The second, uh, point of view on AI is our developers are using AI in their code base because they are developing applications and they want to do things more efficient, right? So you need to detect that they're using AI in the code base and you need to govern that they're using AI based on your policies because, you know, we, uh, uh, pure is being used in 10% of Fortune 500.

Every, every company in Fortune 500 has a different policy of using and governing a ai. So think about this again, I'm going back to our initial conversation. If you have a code dral that holds PII data and this PII data is being exposed by an API that this API is using open AI framework, then it's a critical risk to the business.

And then you want to prevent it or trigger a pen test or a threat mode or a security review or compliance review proactively when the developer adds this AI to this high business impact code repository. Does this make sense, these two different angles, like how we use AI in our deep code analysis engine and how we govern AI usage in our customer's code base. Do you think we're Also getting to the point now where governments and companies and regulators are just, for lack of a better phrase, fed up and they may not know exactly how to go fix this problem, but it seems like they're putting regulations and laws in the books that say, thou shall fix this without necessarily understanding the mechanics of that, but are, or is the bar getting raised here?

The short answer is yes, absolutely. Why? The, the bar is getting raised here because the sophistication of attacks that we see in the wide across supply chain and across a, um, applicative code and across ai.

So yes, I am supportive and I see it that the bar is getting higher and higher, but the challenge is not with the bar. The challenge is how to take the regulations and the requirements and the security controls and automate them because you don't have enough manpower, okay, to take all these security controls and validate them automatically on every code change. And, and Michael, unfortunately, I can't show it right now, but, uh, we have, and we're going to release a research that proves that in the last six months in across our customers, there was an exponential growth, growth in the code changes because of the use of ai.

So think about millions of code changes in a day, how you can automate that. Every code change or material change follows the security controls from these regulations. You cannot, and this is I think, the challenge.

The challenge is not from, uh, the governing the government that puts more guard rates or more, um, security controls and requirements, uh, from this, uh, f regulatory framework or another. The challenge that businesses will face in the next three years is how to automate the validation and the assurance of security controls on their development processes. And it goes back, now we're closing the circle here.

It goes back to your, I think second or third question where I cannot wait until the end of the development process where someone based on a questionnaire will tell me, Hey, Idan, you need to go back because you're not following the regulation or these requirements. No, because then my business will die and I will, will never be able to innovate and release more and more features to, to our customers. So remember these words in the next three years, the biggest challenge will be how you take the regulations and the requirements and automate them throughout the development process.

This will be a CIO and a CSO challenge. All right folks, the first rule of software development is any time that you encounter a bottleneck, automate it. Second rule is if you encounter an application security issue, C roll number one.

Hey ya, Don, thanks to being on the show. Great, great. Um, you know, way to close this.

All right. Hey guys, thanks for watching all of this and back to you folks in the studio.