Predictions For Software Supply Chain Security In 2026

In this episode of ConversingLabs Podcast, host Paul Roberts interviews ReversingLabs Chief Trust Officer Saša Zdjelar about the recent Notebook++ hack and what he thinks software supply chain security will look like in 2026. The two will also discuss the findings of RL’s fourth annual report on the subject, which offers six predictions for how threats will evolve, as well as how security teams will respond. Also, Saša will share his take that the technology industry needs to move away from a “move fast and break things” mindset in order to best secure software supply chains.

EPISODE TRANSCRIPT

Paul Roberts: Hey everybody, and welcome to another episode of ConversingLabs. I am your host, Paul Roberts and I'm the director of editorial and content here at ReversingLabs. This is a podcast where we dig into the latest developments in areas like threat analysis and software supply chain security, and I'm thrilled to welcome to today's podcast my colleague, our Chief Trust Officer, Saša Zdjelar. Saša, welcome. It's good to have you in the studio.

Saša Zdjelar: Thank you. Thank you. Really looking forward to it. This is like my first one with you, Paul, on ConversingLabs, so I'm looking forward to this one and hopefully many more.

Paul Roberts: Is that true? We haven't had you on ConversingLabs before?

Saša Zdjelar: Yeah.

Paul Roberts: Oh my god. 

Saša Zdjelar: Yeah. First time. I think it's like this absolutely amazing brand and thing that we have, and-

Paul Roberts: Thank you.

Saša Zdjelar: I think you do an amazing job at it.

Paul Roberts: Thanks.

Saša Zdjelar: Thrilled to be here and looking forward to doing more.

Paul Roberts: Oh, we're looking to have you. So we're gonna be talking about a couple things today.

First of all, the issue of software supply chain risks and how that software supply chain landscape is changing. We just released our state of Software Supply Chain Security Report for 2026. We're gonna dig into some of our findings that, and some of our predictions, just as important, predictions and recommendations for companies to deal with supply chain risk in 2026.

Saša, you are particularly well suited to lead that conversation. You've got 20 years of experience working for Fortune 10 companies, global executive leadership experience, including serving for more than 16 years for a Fortune 1 company, also known as ExxonMobil. And then as a Senior Vice President for Enterprise Security and Security Assurance at Salesforce, another company people may have heard of.

And we're gonna talk about, you recently wrote a really interesting piece on Cyber Scoop, an opinion piece, talking about this culture of move fast and break things that is breaking as we speak and what maybe needs to happen in the wake of move fast and break things, what our new tech culture needs to be.

A lot to talk about Saša. Maybe let's start by just having you introduce yourself to the audience and tell 'em a little bit about, the work that you've done, prior to coming on board here at RL and what you do here at RL.

Saša Zdjelar: Great. Yeah, Saša Zdjelar, I'm the Chief Trust Officer at ReversingLabs as Paul mentioned.

And yeah, I've had a good bit of experience in very large enterprise. But I think maybe the piece that is pretty relevant to our conversation here is, I had the opportunity to see what this challenge, let's say, software supply chain challenge looks like from both a very large buyer and consumer of global technology and software, and then at Salesforce through a very large, actually the world's largest enterprise software producer or supplier of those technologies. So seeing kind of both sides of this equation, what it's like to have the accountability of bringing in, unbelievably important business critical ERP platforms to run giant corporate value chains that basically run the company, and you're entirely dependent on someone else's software. So think platforms like, ERP platforms, SAP in the case of the oil and gas industry where I spent a lot of time in energy, things like products from Honeywell, that run your refinery, so big platforms. And then at Salesforce, I would say that the real daily responsibility and accountability of knowing that, what we were shipping to our customers, was again, going to run in their environments in a highly privileged context. So whether that's, Slack, whether that's MuleSoft whether that's any of the sales cloud, commerce cloud, any of the things that, again, makes a business function and work. So I've seen this challenge from both sides.

And I would say until recently or until ReversingLabs put some solutions on the market, really neither side had particularly good tooling and technology to help them do this. Up until now we've spent a lot of time on a lot of kind of security theater or things in the absence of controls that we could do, and now luckily we have ReversingLabs' capabilities to help companies really have a good actual control in this. But the space is not getting any easier. I know we're gonna dive deeper into this, over the next few minutes, but, all you have to do is refresh the news and it seems like every time you do, you see some new, Shai-hulud this or Notepad+ or some new npm package that's a new worm that's included in, who knows how many software packages out there. This is not a problem that's going away. In fact, I think some of our state of software supply chain kind of reporting says that we have a significant uptick in this npm and other open source activity. This is a problem only getting bigger.

Paul Roberts: Absolutely. And in fact you tipped the hat to one of the things we're gonna dig into right now, which is, this problem of software supply chain security, and you mentioned Notepad++. This was a story that broke earlier this week related to Notepad++, which is a very widely used code editing application, independent.

And it was the vector of an attack, very targeted attack on individuals, most of them in Vietnam, El Salvador, Australia, most non-US, apparently attributed to a Chinese threat actor. And really interesting how this played out. It is a software supply chain security attack clearly, but it's a little bit different from what we're used to. I'd be interested in kind of your thoughts on the Notepad++ compromise, Saša, and what struck you about it?

Saša Zdjelar: Yeah, I think so first of all, unfortunate that, the poster child of that kind of started this conversation or that continues the conversation is Notepad++ 'cause it's, I think it's otherwise an unbelievably well-liked, super popular piece of productivity software for not just developers, but anyone that wants any kind of markup or organization to their note taking tabs. It's super, it's a great product. So unfortunate that it's in their context that we're having this conversation, but they were the most recent compromised in this scenario.

They've put out a public statement about it. What might be a little bit buried in the story that people may not realize is we talk about all these under the umbrella of software supply chain, and it is, it's a software supply chain attack and breach. What this one, to me, uniquely highlights is, they could have been, and I don't know if they weren't or were, but they could have been doing everything exactly right in developing the software, right in the CI/CD pipeline and code checking and static code analysis and SAST/DAST all that stuff.

They could have been doing everything perfectly and still have had this problem because the compromise in this scenario was of the infrastructure hosting the updates. So what to me it says is yes, you want, all the attestations, that the vendors are doing things right. You want them to prove things. You want 'em to have verifiable builds and things like that. It's not it's not a replacement for your own, maybe don't trust and verify that and verify part continues to be unbelievably important. Because, it was the compromise of the hosting infrastructure at the end, pushing out the updates and in a very targeted way. Right? 99 point, I don't know, multiple nines of the customers or of users of Notepad++ got the legitimate version. They got the good version of this. But a very targeted subset of people around the planet because of this particular APT group's target profile, a specific subset of people were redirected to this nefarious or malicious build and got the bad version, right? So the key is what could any company downloading this and bringing this into their environment, what can they do to ensure that despite the vendor making all the claims and doing hopefully all the things right, that still doesn't mean that a bad thing can't walk into your environment. So I think that's like the one unique thing about this. It was the hosting infrastructure that got compromised. It still led to, a supply chain compromise.

So then that's one interesting thing, the second one that I would just highlight is I think this is a great example of how talking about COTS or commercial off the shelf can be a great example of commercial doesn't have to cost you anything. Commercial doesn't always just mean when the procurement department has an invoice where they've paid money for something, right? This is still commercial off the shelf software. Because it's still someone else that developed it. It's under some sort of third party license. You didn't develop it, you don't have the source. It's still COTS or commercial off the shelf software. So you need to think about that as well, that, oftentimes when we talk about what's your strategy for COTS? I think people's heads, and mindset tends to gravitate towards those things where you pay something, there's a contract, there's an invoice. And that doesn't always mean that, right? It can be, highly distributed, very popular productivity tools like this.

Paul Roberts: Right, and their inventory may hinge on going to finance and saying just give us a list of everything that we're licensing, that we're paying to license. And okay, here's our software inventory. It's no, it isn't. And in fact yeah, so this is a free tool might be widely used within your organization, but invisible to you from a cost perspective. And then there's, of course it's not even like the Notepad++ app is necessarily compromised. It's the update infrastructure, right, that Notepad++ is relying on another vendor to provide. And in fact, when this first came out and people were like what are the IOCs? Notepad++ was like, yeah, we don't know because it's not our infrastructure, it's our partner's infrastructure and we'll get 'em to you when we have 'em, which was kind of like, okay. What ended up happening? Yeah, go ahead.

Saša Zdjelar: I think maybe the other thing that I would say is, what this continues to confirm for me is that the binary is where the truth lives, right? All the other stuff before the binary is really good promises, aspirations, hopes, dreams, whatever. But the binary is the source of truth. It is what you ultimately got from that vendor, from all the layers: developers, imports, includes, build, CI/CD pipelines, hosting infrastructures, third parties involved, distributors, whatever. The only truth of what you actually got from that vendor lives in the binary. It's the thing that you actually got. So it continues to be very important to be able to do binary analysis.

Paul Roberts: And in this case, what happened was this kind of bespoke update application that it used was manipulated so that certain users, and this was targeted at individuals and in certain organizations when they went to get that update. They got redirected to a site that installed this malicious program. Rapid7 did a really detailed analysis of it. And it was basically a downloader and they named it Chrysalis, but it was net new malware, it had never been seen before. Clearly sophisticated and designed for persistence. How do you spot that as an organization? 'Cause it's coming from a trusted source, right? Like you said, it comes down to actually doing analysis of that binary and being like, yeah, this is not Notepad++ or it is Notepad++, but there's a whole lot of behavior in here that new different and malicious.

Saša Zdjelar: I think what it's highlighting as well is that the overall trust model is fundamentally broken. We, you said it's coming from a trusted source. I would say that sort of, that concept of trusted something, trusted source, trusted vendor, if it's still exists at all, I would say it's almost non-existent, but it's certainly eroding if it even exists anymore at all. I would say there's no such vendor and we used to be able to point at some of the largest, maybe those who make our OS or whoever as they must have their act together. And pretty much all of them, I couldn't point to a single one that has not given us some reason to no longer believe that they can be trusted.

So this concept of we trusted the domain, we trusted the update server, we trusted the hosting provider. Every single one of these trust assumptions was exploitable. So I think that the over the general trust model is just fundamentally broken, and we have to get back to this concept of the thing you actually deliver to me, ultimately, the binary, that is where the truth lives, and that is the thing I need to analyze.

Paul Roberts: And this problem of trust with supply chains is obviously, the Notepad++ in some ways was a little bit of an outlier in terms of how that attack was structured and played out. Yeah.

Much more common are malicious or compromised dependencies or things like that. And that's what, our most recent Software Supply Chain Security Report came out in late January. This is basically a report that pulls together a lot of the data that ReversingLabs has gathered via our Spectra platform over the year, both on malware and software threats as well as on software supply chain risks.

Really interesting report and some very eye raising discoveries. Top of the top of that is, malicious open source packages, our detection of them via Spectra, jumped by 73% in the last year, and almost all of that was due to a spike on the npm platform. Obviously one of the most widely used open source repos. Saša, I'm interested in your thoughts on that. Open source risks, a lot gets written about it. What are your thoughts on how well we're doing addressing this risk? Because clearly, those threats are going up.

Saša Zdjelar: Look, I think you just said it best for how well we're doing as an industry. I think there's some very interesting corollaries that we can take. So let's look at some of what you've mentioned. I think I don't know the exact number, but it's 70 plus 72, 73% increase in malicious OSS packages. Again, the world runs on open source.

We've heard that phrase over and over again. A hundred percent true. The world runs on open source. The one minor disclaimer I'd put on that is, but your company doesn't. Your company runs on commercial packages, however, those commercial packages are full of open source and where do a ton of open source packages end up used by commercial software.

So the problem is one and the same. Now, it's, I would say the outcome is not at all surprising. It's a very predictable outcome when you have an ecosystem that's built on implicit trust. So open source repos, like npm are essentially open door warehouses. Anyone can publish. The barrier to entry for attackers is almost zero. And one of the, nastiest things that happens is you'll have an incredibly popular package by name that for whatever reason goes outta support gets retired and a bad guy picks up the exact same name and starts publishing nefarious packages. Or they compromise a developer through social engineering, or they compromise them directly through their own login to platforms where they check in code. So I think that's one huge thing.

Shai-hulud was also a watershed moment I think in the industry. It was a self-replicating registry, native worm. It compromised, I think, almost either just under or just over a thousand npm packages. Including some that have millions of weekly downloads. So like this, incredible, this worm-ification of supply chain threats I would predict is going to only accelerate.

The other thing you mentioned is, npm was the big one. It accounted for, I think, 90%. Again, a little, maybe a little bit more, a little bit less, but that's also unsurprising. It's the world's largest software registry. Yeah. It powers the most popular frameworks, JavaScript, node.js, that type of stuff that is basically the backbone of modern web applications. If you think about the blast radius, that is staggering. There are, I think, over 10,000 malicious packages detected in a single year, and that's in this past year, and that's more than double from the prior year. So again, the problem is only getting worse.

Yeah, the corollary I was gonna say is if you look at I love analogies 'cause I think they help me make something that may be a little bit abstract to someone a little bit more real. If you look at what happened in the auto industry when it also is for anyone who's fascinated by this type of stuff, you might wanna look 'cause it's fascinating that it took us like 40 to 70 years after cars were made and you had these, four to 12,000 pound metal death machines, moving around roads, sharing the roads with horses and pedestrians and humans and babies. It took 40 to 70 years before we said maybe we should put some controls or guardrails or figure out how to do this safely. To one of our other topics is move fast and break things. It's shocking that it took literally decades before people said, maybe it's time to have some standards around this, seat belts and things like that.

But my point is, what happened in that industry? You had this, is it getting better? Is it getting better? No, quite the opposite. It got massively worse. Massively worse before, and I wanna say in the mid seventies, it was actually, I think one of the things we can thank Ralph Nader for, right? And at that time, a lot of the highway transportation, safety administration, they introduced things over time. They were like let's put in seat belts and then let's think about airbags and let's think about crumple zones so that when you hit your hood, doesn't go through the windshield and slice your head off. Let's think about road signs that break off instead of bend and become spears. Let's think about guardrails on the side, let's think about barriers that if you run into them, they're full of water or powder and something hard to absorb hit.

Paul Roberts: Even like the dials on the radio, they used to, impale people and getting absolutely getting car makers to just make safer like radio dials.

Saša Zdjelar: That's it

Paul Roberts: It was a big thing.

Saša Zdjelar: That's it. So over time, as they introduced more and more of these things, there's these amazing charts. I actually made one, like for a presentation 15 plus years ago, that showed for every one of these incremental things that were added, you see the curve legitimately bending towards better, whether it was, traffic safety accidents that resulted in either, significant injury or death or things like that.

To me it's gonna take that sort of an effort, an effort to introduce over time, significant guardrails, controls, and ways to move fast and, do it in a smart way. Right now we're, I think at a point where we're still in for getting a lot worse before it will get better.

Paul Roberts: One of the things that we did see in the data that we collected was this, and you mentioned it, the shift towards attacking very widely used open source packages and maintainers. Previously, a lot of these supply chain attacks were focused on, obscure little ignored packages.

Maybe they had just, been abandoned or whatever, but they were still widely used. But that really shifted in the last year. We saw attackers going after some of the most prominent open source maintainers and some of the most widely used open source packages with literally hundreds of millions of weekly downloads, billions of lifetime downloads.

If you were to talk to developer/development organizations right now about how to process that, because there are so many people are using these packages, what would your advice be and what would you say they need to start doing to compensate for that? Because almost certainly we're gonna see more of it, right? It's not like that's something specific to 2025 that's gonna disappear in 2026.

Saša Zdjelar: Yeah I would say, if the denominator were static, if it was okay, now we know the, all of the problems and how bad it could be. Now let's think about how we tackle. I would say if that were our paradigm, then we could have one kind of conversation. Unfortunately, even that is not true. The denominator is also shifting, right? As we have AI coming in and as we have ML models being now a part of our development work and as we have, things that did not exactly exist, a decade plus ago, which is things like dev tooling and VS Code. It's not just is the code safe, it's everything from the IDE, the extensions, the CI/CD infrastructure, it's basically a world where if you compromise the tool, you compromise everything that tool touches. So it's not just the code being gone after it's any single thing that is a weakness in the overall chain.

There's a couple of, used or maybe now stale phrases in InfoSec that are like, why hack in or break in when you can log in? Or you hear people say things like. Hackers are like water. They take the path of least resistance.

And I think that part is true. A lot of these are actual businesses. These nefarious attacker groups are legitimate businesses. They also are unbelievably efficient at what they do. They would much rather spend a lot less effort and money and resources by compromising the weakest thing, instead of spending a lot of time and resources trying to brute force the login for something. There might be a much easier way to do that.

So I think that's one is like the whole dev tooling problem. And I, to your point about what would I tell developers is maybe start by looking at that first, looking at again, your overall stack, your IDE, the extensions you use, your CI/CD infrastructure, what you're using, the marketplace. Look at that.

The other one is, and we did some fantastic research on this last year in nullifAI. But the dangers that are now coming with using ML models and AI, that's an entire new frontier for supply chain that didn't exist before. So if you look at the campaign on Hugging Face, where there was malware embedded in the ML model using the Pickle format.

That's not a theoretical problem, that actually happens. So you hear people say things like, oh, be careful about, your AI model being poisoned or malware and that, or something like that. People are like, oh, that's just fear mongering. Or, how could that happen? And it happened, it legitimately happened and it will only keep happening more.

One, 'cause I think it's not as well understood that it could, and that's just another supply chain problem. In fact, an amplified one. But the other reason is, again, unless you have ReversingLabs, you don't actually have tooling that can help you find this. What tool would you point at an ML model that you're downloading to see if it has been tampered with or contains malware, especially as they're very large, complex files.

The other one is, MCP servers. Now, it's becoming very, vibe coding and using MCP servers and, stitching that stuff together. Okay. Do you know that MCP server is an infrastructure that can be trusted? How do you know you're pointing at the one you actually think you're pointing at?

So this concept of a malicious MCP server, we found those, they were being distributed via npm, and you have enterprises and individuals who are rushing to adopt AI. You have a lot of pressure from the business to do it. So now you have, this is not a problem, which that's another problem. My point around the denominator also shifting. You have even more things to worry about.

Paul Roberts: We're reading now about the MoltBot skills compromise, right? Where you have these malicious skills uploaded, 600 of them, right? That I mean it, things are changing so rapidly, which is amazing. Like the capabilities of these AI platforms with its cloud code or whatever is just jaw dropping. And yet, the risk of plunging ahead, just leaning into the cool features and not thinking about, hold on, like what level of access does this thing have to my data and applications and what's running on my system and my network environment? What is exactly in these skills and other things that I'm uploading and running, is really, I don't think we've seen anything like it in the past in terms of the risk.

Saša Zdjelar: The other thing is, a lot of times these open source registries that we're talking about. The other thing that again, maybe doesn't get as much press as it should is just how dangerous the amount of secrets exposure that's living in that land as well.

We have everything from private keys, API keys, access tokens. That's probably 80%, if not more. But these are the keys to the kingdom, and they're being left in plain sight in public repos, like npm. And it's not the only one, but npm kind of gets a lot of press 'cause they're the biggest ones. If you look at the, like the Trust Wallet one that we wrote about in the Cyber Scoop piece.

In that scenario, Shai-hulud leaked developer GitHub credentials that led to attackers accessing source code and a Chrome web store, API key, which led to the upload or inclusion of a malicious extension, which led to eight and a half or 10 or whatever the number was, million dollars being stolen.

So one secret exposure had this giant chain or linked set of consequences. Yep. That are hard to fathom. So I'll just go back to my original. I think the common thread in all of these is that the trust model is simply broken implicit trust in these open source repos and the update mechanisms and the hosting providers and developer tools.

It's all being exploited. So the answer is continuous verification, but that means the ability to actually technically inspect the software.

Paul Roberts: Can we talk about the elephant in the SOC, which is actually one of the chapters in our report. The elephant in the SOC is of course, the risks that are lurking in the commercial software that your organization, whether you're a Fortune 100 or local dentist's office are relying on whether it's locally run, whether it's cloud-based. As we know, just from reading the headlines this year, there are huge risks lurking in that software. We saw the compromise of F5. We saw the Salt Typhoon or Volt Typhoon attacks targeting Cisco iOS. You know how many people out there are using Cisco hardware? A hundred percent of companies, something like that? So what do we do about this risk in commercial software that we all rely on and should it fall to the SOC to start taking these supply chain risks into their scope, under their umbrella and saying, yeah, we gotta manage these and monitor these just like we do endpoint network traffic and stuff like that.

Saša Zdjelar: Yeah. I think this is such a huge topic, not really being talked about enough, or at least in the right way. And I would almost argue like we should maybe do a dedicated episode just for this on a future ConversingLabs. But if you think about commercial software being brought into an organization, when people hear software, their mind may not gravitate towards F5, Big IP or Cisco or things like that. Most of the time, right, what you're actually getting is a giant image. You're getting software that you run on a VM that acts, it's a software based router or firewall or whatever. It's just software, but it comes to you in the form of a massive image or container or VM or whatever it.

So massive that again, there is no traditional tooling outside of ReversingLabs. I don't know of anything that can take this sort of, 10, 20, 30, 40 gig package or more. And make sense of it, analyze it, tell you exactly what's inside it, tell you what risks exist. Not just vulnerabilities, but even bigger risks, malware, tampering, embedded secrets, all kinds of problems that are really bad.

I would say the conversation we're not having enough about is these sorts of products, and again, this is not to call out any specific vendor, it's any vendor like this used by a company. You said Cisco, Palo Alto, Versa, whoever a company might be using. I used to do this, like you said, a Fortune 10 company.

I know what it took to get thousands of network devices, thousands, into 160 plus countries around the world. In some cases it sat in customs for nine months. These were multi-year and sometimes up to a decade projects just to get these capabilities into an environment. So imagine if you ever were faced with trying to replace one like F5, they had the breach, their source code was exfiltrated.

Now it's, many believe open hunting season on any net new vulnerabilities that are not yet known about. And so if you wanted to say boy, we want to change vendors, or something like that, could you even do that? Is that even feasible? How long would it take you?

There are some things that you bring in. You like a competitor, you swap it out, six months later, a little bit of change management, you're good to go. Some are not. Some like these underlying, I'll call 'em lowercase critical infrastructure for any company. Your critical infrastructure certainly comprises some of these giant network vendors that you bring in to do firewalls and software defined networking and secure web gateway capabilities, VPN, these are very hard to ever change.

In those scenarios, I would say far more care should go into the early screening and the ongoing monitoring of what's really inside these kinds of packages. So you mentioned a few that are a good example. VPN is another big one. There's been a lot of news Ivanti VPN Compromise. There were also Chinese APT groups that were targeting, Microsoft SharePoint, with zero days. There's just this-

Paul Roberts: Yep.

Saša Zdjelar: These attacks on-

Paul Roberts: Citrix yep.

Saša Zdjelar: Yeah, exactly. Yeah, absolutely. And then we have historic ones that put some of this stuff on the map, Circle CI, 3CX, SolarWinds, like these go back, a decade or more and they're only accelerating. What does it mean for an enterprise? I would say if you're a supplier, if you're one of the vendors that are used by these companies. I would say you need to prioritize securing your releases.

Now that doesn't mean just the traditional AppSec stuff, SAST/DAST, SCA, yeah, you need to do all of that. That can lead to bad problems. None of that is you don't get, you don't get to stop doing that. That all still matters and it's very important. However, as we learn from this Notepad++ and so many of these others, that is not where your responsibility ends.

You could still ship tremendous problems outside of cross site scripting that are far worse. In the form of tampered piece of software or a backdoor or a piece of malware, none of which will ever have anything to do with SAST or DAST scanning or any manual pen testing. None of that will find it right?

So I would say you need to analyze that final compiled binary before you ship it. 'cause again, I'm gonna argue that is the truth. The binary is the source of truth.

Paul Roberts: Right. I like the phrase necessary but not sufficient. So that's the traditional AppSec stuff. Yes, absolutely. Gotta keep doing it. Endpoint security. Sure. Of course. Network monitoring. Absolutely. Is it sufficient? No. And we saw that, you brought up 3CX, which is ancient history at this point, but I always I think of that the 3CX desktop app compromise is a VoIP application, very widely used in the crypto industry, which may be what inspired that attack.

But that was one where, as we wrote on our blog, there were some real red flags in the, in that compromised update from 3CX signed update from the vendor that if you had been looking for them, would've alerted you to the fact that something had happened. Was it a clear malware detection? No. Was it reason to dig deeper and be like, what's going on here? Yes. As it turned out, it started setting off EDR systems and stuff like that. And there was a bunch of days where it was really unclear whether it's legitimate, whether these are false positives on EDR, and so those are the types of scenarios that companies really need to be thinking about and preparing for.

Okay. Let's talk a little bit just about some of our predictions for 2026 and beyond in our Software Supply Chain Security Report. And I want to get your thoughts. Let's start with the shift left prediction. Do you see that happening already? SOC starting to take on some of this supply chain stuff? Or is that still- more time is gonna need to pass before that actually happens? And I would say MSSPs might go into that as well.

Saša Zdjelar: Yeah. I would say with a lot of other, like with a lot of other trends, you see the most mature, well-resourced organizations moving into that space already.

And then everything else, you'll have early adopters, you'll have, quick followers and you'll have kind of laggards. I would say this is one space where- some of the things driving it, let's go back to a few years ago, right? Several of us, myself included, had a very unpleasant holiday season around Log4j and you know what that meant?

And companies said, okay, what, that's a component And so what is a component? Oh, that's this thing that's in your software. Wait I thought all software was, people on keyboards typing software. It turns out that's not the case. You know, less and less software these days is first party typed or developed. And a lot of it is constructed. A lot of it is oh, someone already wrote a login routine, let's reuse it. Someone already wrote something for crash analytics. Let's throw that in. So there's a lot of, software construction that happens and then some native software development.

So Log4j for a lot of people in the SOC, to your point, was kinda, they're not AppSec people, those are not their backgrounds or even developers. Developer backgrounds, they don't, didn't necessarily understand what goes into the developmental software. And so there was first this learning curve of yeah, there's this component, and SOCs were saying, great, where is it? Let's go. If they're like here's the problem we don't actually know where it is. So step one, SOC: Go find where we have this. How would we do that? The vendor sounds like they're gonna have a script you can run, in a few days that will help you go look for this.

And we had some of that with Heart Bleed and a few others where like the SOC was caught without capabilities and you had to just make it up, on the fly. So then they said, okay, is this a one-off problem or is this a problem that we may see a lot more of?

And I don't know if anyone who in that analysis concluded it's a one-off. We won't see any more of that. In fact, the, all the stats tell us, we've seen a lot more of that and we will see even more of it. So now the, SOCs are asking, hold on, as part of our basic preparedness response, playbooks, our native capabilities- for the next time there's a Log7z, I need to not, not know where I have this, like how do I know where this stuff is? So I can go very quickly say, these are our 37 impacted systems, let's go patch, triage, quarantine, whatever. Then you have the advent of something called SBOM or software bill of materials.

So something that can tell you what's in the software you're bringing in. So to your point about SOC shifting left, what we're seeing now, and in fact multiple Fortune One, entities that we're very well aware of and partnered with, are starting to use these processes as part of their onboarding.

They're saying software does not get into this environment until it flows through ReversingLabs, until it does its full analysis. Again, the sources, the binary is a source of truth and only when it's deemed clean or sufficiently clean. Not perfect, things we can live with and none of the things that we can't live with.

And we have a full software bill of materials. In other words, we have a catalog of this version that we brought in, and we will have an updated catalog of the ingredients list and exactly what's in it for every future version. Now this is something we feel comfortable introducing into our production.

So that's where I think we're gonna see a movement of SOC shifting left, is they will just have more of a role in the initial screening and onboarding of software to fully understand what is in this piece of software, bringing in, do we have the tooling and capabilities to inspect it, detect it, monitor it. So I think that shift will definitely happen.

Paul Roberts: Okay. One of the other predictions for our Software Supply Chain Security Report for 2026 was just about AI. And you know that AI is gonna be driving software development, but also software risk. I'm not gonna ask you to take on the whole AI, but I think my question for you would actually be, for companies- that is every company that is leaning into AI to accelerate development, product development, code writing, and so on. And you're very well informed on this. What are your recommendations to them as to, we talked about the Hugging Face stuff and nullifAI attack, what are your recommendations for them on how to manage the risk that goes along with the reward of AI powered coding?

Saša Zdjelar: Another topic I would say we should carve out a whole separate episode for 'cause it is just such a massive space. I am not at all an AI doom and gloom person. Quite the opposite. I'm actually unbelievably excited by AI and what it brings. But it also like we have to go into it with eyes wide open, knowing that it is also a massive new, maybe the biggest. 'cause again, anything brand new, we don't yet have tooling. We don't have full maturity around it.

There is no one that can say, I have 35 years of experience with AI. I'm sorry if you say that, you're lying. We're all learning. Some people have a little bit of a head start on others, but like we're all within a few years of each other as far as knowledge and experience.

The whole space is new enough. So with that comes massive risk, just simply of the unknown. It is probably the single biggest new attack surface in any enterprise. This combination of pressure to adopt quickly and roll out quickly to not fall behind. 'cause, Acme Corp over there, down the street, they're using it and getting all this huge value.

So we have to have it as well. This pressure for fast, again, back to, move fast and break things. I think history has taught us that we moved fast and we broke things, and I think the implications of doing that with AI are unbelievable. Unbelievable. Your own proprietary information, getting into public models, making horrible decisions, 'cause you're relying on hallucinations and just completely made up answers.

Paul Roberts: Think with that, we're gonna bring this to a wrap and Saša, thank you so much for joining us here on ConversingLabs. Like you said, we're gonna have to do another one of these where we can just dig these questions around AI supply chain and AI's benefit to security and also challenges facing security. Get ready to see a invite land on your calendar. And thanks everybody who tuned in. We've got more ConversingLabs episodes coming up in the weeks ahead. Stay tuned and again, Saša thank you. Check out if you haven't our Software Supply Chain Security 2026 Report. And we will do that again. Talk to you later. Bye Saša.

Saša Zdjelar: Thank you.