Nick Mistry on the AppSec Confidence Gap Revealed at RSAC

Hey guys, thanks for the throw. We're here with Nick Mistry, who's the CSO for Lineage, and we're talking about a survey they did at the recent RSAC conference and it talks about well, software supply chains and whether or not they're secure and maybe to what degree. Nick, welcome to the show.

Thank you for having me. So as you conducted this survey during the event, um, what happened in here that surprised you? Or was this, was there something that's going on?

'cause I feel like we've been talking about this issue for a long, long time now, and it's not clear to me that we're making enough progress and or for that matter, whether people actually understand what the issues are. No, that's a, that's a very good point. You know, some things that, uh, definitely, uh, surprise me, but uh, shouldn't be surprising is there seems to be, um, a lot of confidence in AI's role to enhance software supply chain security, which, which I think illustrates the promise of, of AI in terms of what it can do.

And then on the flip side, what was really interesting, um, was the fact that, you know, when it comes to understanding software supply chains, you know, with simple capabilities like software build materials or SBOs or ability to really, you know, drive vulnerabilities out of the supply chain, there, there seems to be a lot, a pretty big gap. Um, so I think there's a, a lot of, uh, I guess, expectations on ai. At the same time, it, it does seem to validate that we haven't made as much progress in understanding and grappling with the software supply chain risks.

So we've been having these conversations for a long time now, and I feel like the process is fundamentally flawed. I mean, bunch of security people run around and create a list of vulnerabilities, throw it over the wall to a bunch of developers who go, well, a I may not have time for that. And B I'm pretty sure most of these vulnerabilities don't even exist.

You know, you're exactly right. The process is definitely broken, right, in terms of dealing with vulnerabilities, as you mentioned, one group scanning it, and then the other group and that group is sending it over the wall to the other group. And there's a lot of contention, right?

What's really needed is in the, in this era where the software development velocity is, is increasing faster than people can actually prioritize and patch and maintain software is, uh, a capability where both organizations can see the risks in a unified view. And equally important, understand what to do, right? What is the appropriate fix.

Not every remediation, uh, is equal in terms for it's, uh, the bang for your buck, if you will, right? And a lot of that, you know, can be driven centrally in a way that both groups can agree on. What are the right risks to resolve and what are actually the right remediation steps to, uh, remediate the most risks out of software.

So I think, think there's a huge opportunity there. Absolutely. Given all that, I mean, what's the cure for this?

What's the remedy that we should be putting together? Because, I mean, I can't really put cybersecurity people in every app dev team and maybe I can train the app dev people to be better at security, but you know, the, the spirit has to be willing, right? No, a hundred percent, right.

And I think the, the challenge as I mentioned before is that, uh, the speed at which software is changing, plus the risks are pretty dynamic. And then you get these two groups that are working in silos. Uh, it just exasperates the situation.

So, uh, one, you know, one of the solutions that been very effective for, for us at least in terms of what we're seeing is starting with a, you know, you know, everybody talks about software build materials and SBOs as a static view as a laundry list or ingredients list of software. It's actually much more important that, so software bill of materials can be operationalized to, uh, identify all of the risks. But equally important is the fact that now that you have a software bill of materials, you also know which remediations will be able to drive the, the largest number of fixes in your vulnerability.

You can even determine with the right intelligence around, you know, operationalizing a software build material, um, you know, which, which ones actually have a fix available. Not all patches are available for most of these vulnerabilities. And you can centrally start making some decisions, um, you know, together versus, you know, having a, a separate scan and a separate result.

We can see things also in real time if we instrument this within the CICD pipeline. So both groups are seeing the same thing, uh, and analyzing and coming up with, uh, you know, what are the right steps to reduce risk. Things too that comes up is that not everything that needs to be fixed is something I have control over as a developer.

'cause it may have been created by some third party open source maintainer who I may or may not be able to reach. Yeah, no, that's exactly correct. And you most likely won't be able to reach at all, right?

And so those, those vulnerabilities won't get fixed. So what are the options? Right?

There are, you know, obviously, you know, replacing that open source with, with another one is an option, very painful option and almost impossible. The other one is compensating controls. Like what can you do to mitigate the risks that we see in that vulnerability?

Uh, and then, you know, the, the third is one of the things that we launched is gold open source. So this would be pre-vetted vulnerability free open source. And what we'll do is we'll actually create, uh, a fix if there's no fix, and then contribute it back to gold open source.

One of the things that has kind of come up in recent months, and it's been an issue for a while to be honest, but people are afraid to patch something 'cause they're worried that the application will break and that they might possibly, um, lose some revenue or there'll be some disruption to the business. And yet, I wonder if we reached a point now where the potential loss is generated by some vulnerability that gets exploited, it might be even higher than the application being down. Uh, well, I, I think that's a tough one, right?

Absolutely. The risks of the vulnerability being exploited, um, you know, could lead to application being down and then you don't wanna self-inflict a wound by taking down an application or, or, you know, just as bad extending how long it takes to, uh, you know, do the maintenance around that application by introducing breaking changes, going back to the testing cycle, et cetera. Um, you know, so, you know, that is a big concern.

However, you know, throw into the fact that, um, we're seeing AI tools now. So, so, you know, the conventional wisdom was, oh, let's let's look at things like, you know, exploits. Is there a valid exploit already?

And use that in prioritization and other mechanisms to prioritize, to avoid exactly what you're saying, introducing a breaking change. However, we're starting to see that, you know, individuals with, with little expertise, right? A little bit of expertise can actually start creating exploits for these vulnerabilities using a lot of these code AI gen tools, right?

They're actually sophisticated enough now to, you know, drive, uh, and build exploits against vulnerabilities. So, you know, the long, long, long story short around this is I don't think we have a choice. I I think we do have to remediate vulnerabilities.

So one of the things we're looking at is a compatibility analysis. What are the fixes you can make that are compatible with your software that won't break your software? And then equally important, I think, you know, we've made a lot of strides with, with ai and AI has the ability to then also rebuild your source code, rebuild your container, which is what we're working on in a way that it won't break your software and remediate that vulnerability.

And so we fundamentally believe that's kind of the, uh, advantages of AI and where AI can really help is take that detailed analysis, uh, and ability to, uh, rebuild a container or rebuild from source code in a manner that won't break your software. I, I think is, um, is a huge opportunity. You can't walk down the street these days without somebody telling you about their great new AI thing.

We're seeing more AI code than ever. Um, is that code better than it used to be worse, or are we roughly about the same All indications point that, you know, AI generated code i is about the same or worse, right? And worse from many perspective, not only from a risk perspective, but being able to understand, um, you know, what, what is happening with that code?

Especially we're seeing instances of, of AI generated code hallucinating packages, open source packages that it's pointing to, and then adversaries are, you know, understanding that what, what are, what are these package names that are being hallucinated and then create it, and now they've created a malicious package that people are are downloading. So definitely, you know, AI gen code is, is the future and it's just gonna get better over time. But I think we need to, you know, make sure we're aware of what are the risks and being able to detect and manage those risks, you know, uh, within, uh, AI generated code.

So given where we are, I mean, how do I kind of bring these cultures together? Do I take, take, just take them all and throw 'em in a room and lock the door until somebody sees sense? Or is there something I can do as a leader to kind of gently push people in the right direction?

Yeah, no, definitely. You know, there's, there's gotta be a coming together and whether where they merge or they meet, if you will, is this combination of understanding software, which is, you know, I would say most AppSec teams under science software, they're very focused on vulnerabilities. And then on the other side you have the dev teams.

Obviously they're focused on building great capabilities and uh, and velocity of terms in terms of, you know, go, you know, getting to market quickly with new capabilities that add to their business. Having one central view of that. And we've seen when that happens, when there's a joint view of not only identifying risks, but then also being able to understand, uh, what are the fixes that are going to actually reduce the most risk understanding compatibility.

So really is bringing together the challenges the dev teams face in, in real life challenges of making these fixes. Whether it's compatibility issues that will break their software, whether it's things like, you know, there isn't a fix because it's a deep transitive dependency within a direct package or other things. And then also at the same time, having the view from the AppSec perspective that's understanding, okay, what is the critical, how critical is this vulnerability?

You know, what is the dependency tree analysis? And, and really having a unified view. So collectively decisions can be made that optimize for reducing risk and driving efficiency.

And then obviously using tools, uh, you know, such as, you know, some of the AI capabilities we've launched to automate the remediation process, uh, in order to alleviate, you know, the manual effort, uh, around, uh, that, that remediation. Well, folks, you heard it here, empathy goes a long way even in the age of ai. And all we gotta do is kind of agree to a common set of goals and you'd be amazed at how much progress can be made.

Hey, Nick, thanks for being on the show. Thank You. Appreciate it.

All Right, and back to you guys in the studio.