AI Vulnerability Surge Tests Software Supply Chains
Mike Vizard talks with Brian Fox of Sonatype about why AI-assisted vulnerability discovery could create a rapid surge of software supply chain risk. Fox explains that attackers and defenders can now use advanced models to find flaws faster, which could lead to exploit timelines that outpace traditional patching, triage and dependency management processes. The conversation also explores package registry sustainability, organizational bills of materials and why teams should run tabletop exercises to prepare for multiple Log4Shell-scale events in compressed timeframes.
Transcript
Hey folks, we're back here at the Open Source Summit in Minneapolis, and we're here with Ryan, and we're going to have a little chat about, well, what's real and what's not real about all these vulnerabilities that are being discovered using AI tools, because, well, it's certainly a time for concern, but we don't know how much concern. Buddy, welcome to the show. Yeah.
Nice to see you again. Nice to see you. So I think everybody's heard of, unless you've been living under a rock, something about Mythos and something about the fact that there's all these vulnerabilities that are being discovered.
Mm-hmm. And we've been talking about this issue in software and having all these kind of security flaws for years now. I think what's different is it's all coming to a head at once.
Yeah. So how real or not real do you think all this stuff is going to be, and what's the ultimate impact going to be? Yeah.
Even from my perspective, the numbers that I'm hearing feel unbelievable. It feels like that's not real, everything's going to be fine, it's going to be the business as usual. But- Feels Y2K-like.
It does. It does. That is a great analogy.
And Y2K ended up not being a huge thing because we had time to fix all the stuff. It's not that it was made up, it's actually we mobilized and we fixed enough of the software that it really didn't create a catastrophic outcome. I wish I could be super optimistic that's going to happen this time.
The numbers that I'm hearing, that folks are finding of zero-days in software is staggering. " And then I get reports, and I was off by a factor of 10, is not fun. And yes, we've been talking about this for a long time, but the risk is that all of this stuff kind of comes due all at once because the attackers are not going to wait as soon as they get their hands on these things.
And in fact, they already have their hands on these things, because current models with a good harness can do a lot of the same things, right? Yeah. And it's only a matter of time before all the other models catch up.
7, all of those are fairly good, and I think it's sort of a case of, if the software hasn't been thoroughly vetted by the new models and things like that, you're of course going to find a ton of stuff, right? Mm-hmm. If you have been doing that all along and the software's already pretty tight and there's not much to find, that's when the more advanced models might still find some things, but less things.
I think what we're seeing right now is that the majority of the open-source software has not been vetted as thoroughly as, say, Curl, right? Mm-hmm. For lots of different reasons.
And so in some ways, I think it's easy pickings for any of these models to find pretty severe vulnerabilities. The other part of this thing that's a little scary too is the exploits are starting to show up before the patches are in. Yes.
Yes. And that's only going to get faster and faster, right? Absolutely.
During the keynote here, Jim shared the stat, the average time to exploit is minus seven days now, because if I can prompt a tool to find a vulnerability, so can the next guy and the next guy, and they're not all good guys. And so, it's minutes away from discovering the thing to having a potentially working exploit now. That's the difference.
That it used to be hard to chain these things together. And that, by the way, is one of the things that Mythos is apparently very good at, is taking a lot of lows and mediums vulnerabilities that might not normally be a big concern, figuring out how to link them all together and create a catastrophic execution plan. That is very different than what we've seen.
Mm-hmm. And so I don't even think we're experiencing the impact of that potentiality yet. How will this impact application development?
Because for years we've said we don't need to slow down. We can keep running at the speed that we're running at, and we kind of maybe paid lip service to security a little bit, or far too often than we care to admit. Yeah.
But ultimately, will we be forced to slow down, or is it just going to get more costly because we're going to try to keep the same level of speed, but we're going to have to throw more AI at the vulnerability discovery process? Yeah, I don't think we're going to slow down, we're going to speed up. I think in the long enough window, things will return to a new norm.
There's only so many bugs to find in the software. Eventually, the software will be good. The problem is going to be how will we survive getting from where we are to there.
Maybe, and if we will survive getting from here to there. Because like I said, there's so many vulnerabilities that have never been with the software, open-source software hasn't been scanned. There's going to be so much stuff to find, the rush to patch them is going to create new challenges.
The next level of models are going to be even better. The exploits are going to chain all these things together. I think we're in for a bumpy couple of years as we pay down, effectively, all of the security debt all at once.
" Yes. I think all of the above. Yeah.
And it's going to be hard. I think organizations need to be bracing themselves for a massive increase in the number of patches that they need to be able to consume. That part, to me, feels mathematically provable.
We run Maven Central, as you know, where we are where all the open-source components get to the world. We're the last mile of delivery for that. I've been looking at some of the numbers, and I'm anticipating minimum300 to 400% increase in the publishing events that I'm going to have to consume in the next three to six months as everybody starts racing to patch.
That puts strain on my systems, but downstream, all of those patches have to get pulled into software as well, and updates, and all of those kinds of things. And so if you're an organization with a large portfolio, we've been saying this for years, get your organizational bill of materials together. We've been saying this before, Log4Shell, Log4j.
What would you do if you had 10 Log4Shells every day for the next three months? That might be an understatement. I don't think that's alarmist based on what I'm seeing.
We were talking previously about the sustainability of all these services that you guys provide, and you just described the situation where you're seeing a 10, 20, 30-fold increase. 300. 300.
Yeah. What does that do to the economics of the services, and can they be used in their current form? Because a lot of people have embedded them into their workflows.
Yeah. And now they're just hanging on them harder than ever. Oh, absolutely.
When we spoke at the summit last year in Denver, I was just starting to formulate some plans in my mind around this problem, and since then, we convened other package registries together with the OpenSSF. We published an open letter to the world back in October, September, something like that, and we more recently formulated an official working group within the Linux Foundation, and then we published an update to that letter within the last couple of weeks. And so we've been making a lot of progress on changing the norms, trying to think through how do we have industrial-scale usage of these things end up having to be paid for while we keep the mission of delivering open source to teams and to companies worldwide, keep that open and free.
" Mm-hmm. It's different, right? Yeah.
We want to be the library, not next day delivery service from Amazon. It's a different model, and we're unwinding a lot of those patterns. So the industry of package registries has been making decent progress on this.
But yeah, these costs that I was describing, we weren't contemplating those when we raised our hand six months ago and said the economics of this whole thing is not sustainable. That was even maybe a little bit before the bend of what every tool is seeing is the rise in consumption from AI. All of the development, there's a huge jump in the number of GitHub repos.
All of those things are building against package registry, so all of our numbers are up significantly since September. And now you contemplate maybe 130,000 minimally releases that have to jam through on just the Java side alone in the next three to six months. I'm glad we started the conversation a year ago, I guess, is what I would say, because we're kind of already in motion.
It's just the bar has moved a little bit further. How do you have this conversation with the business? " This is a difficult conversation to have.
It is. It turns out physics is physics, right? " I think that's kind of what we're dealing with.
Everybody thought all of these things were free, and so they could just take them and not really do the due diligence, and again, that's what we're dealing with. But yeah, I think in terms of usage of the package registries, for example, yeah, we're finding a lot of use cases that should be paid, nobody had budgeted for them. And I think part of the challenge that I've had is trying to navigate that fairly, equitably, recognizing that something that they've been used to doing for decades suddenly is not okay, and realizing that you can't just snap from one mode to another overnight.
That makes the challenge much harder. If you're talking about organizations that hadn't invested in bill of materials, software supply chain security, I don't know what else to tell you. We've been explaining why that was critical for years, and I almost feel like if you haven't started doing it now, it might be too late.
But there's never a better time than tomorrow, right? You might want to check how that 401 is doing. That's right.
But yeah, seriously, what's your best advice to folks besides checking their retirement accounts? But how to approach this whole thing, and what's the sane thing to do? I think you need to start sitting down and recognizing that this isn't a glitch.
It's not all marketing hype. It's real. It's more of a question of when, not if, and how fast am I going to have to do it?
And seriously, have conversations with your teams. Run some tabletop exercises ASAP to think through, like I said, what would happen if we had 10 Log4Shell-like events in a week, in a day? How will we deal with that?
Where are our gaps? There's no reason not to start preparing, even if you don't understand the full magnitude. At least if you start getting in motion, then you can move in the right direction.
All right. Folks, you heard it here, the technical debt bill, it has come due, and it's time to start digging deep to pay for it. Thank you, my friend.
Thank you. All right. And we'll be back in a minute.