AI-Driven Attacks Make Continuous Patching Essential

Hey guys, thanks for the throw. We're here with Matt Moore, who's the CTO for Chainguard, and we're having a chat about, well, how much progress are we making at resolving all these vulnerability issues that have popped up in the post Mythos era? Because, well, it looks like we're getting something done, but I'm not quite clear how much of that is the total, and what are we looking at.

Matt, how you doing? Welcome to the show. Thanks for having me.

I think you guys have now helped organizations remediate CVEs that are numbered in the thousands. But what's your sense of where are we on this journey at this point? And I do feel like it is something of a race against time, but how much time do we have?

That's a great question. And yeah, I think, as you say, we've helped a lot of people address a lot of CVEs across their environment. Some customers have come to us and said, "We have literally millions of CVEs," if you count all the instances of a service across their production environment, and we've helped them take considerable chunks out of those things.

I think the frontier models are definitely causing that to accelerate. But it was already growing significantly year over year over year, and it's been wild to see how early in the year the number of CVEs reported in 2026. Okay, we've already passed 2025.

2025, it was only partway through the year that we passed 2024. This is growing at a rate that is pretty wild. And the frontier models are really just accelerating that.

But to your point, I think that the models finding all of these vulnerabilities, it's finding novel vulnerabilities now with things like Mythos, but there's so many known vulnerabilities out there that folks haven't patched. " But they haven't addressed the huge backlog of, in some cases, millions of known vulnerabilities in their production environment, right? And so it's sort of like they want to run without crawling and walking, right?

And so I think our existing products sort of help with the crawling and walking, and then things like Athena help with the running. But it's definitely very interesting times we live in. So I don't think a lot of the adversaries have a access to Mythos or any of these more advanced models just yet, but they do have access to AI models that are pretty good, and they're discovering vulnerabilities pretty rapidly.

And if they're known or unknown, doesn't really matter. At the end of the day, they are also able to weaponize those things in a matter of hours now. So, are we kind of looking at a tsunami of attacks that are coming to exploit these vulnerabilities?

And I mean, has that begun, or is this still to come? Yeah, I totally agree. Before we got access to Mythos ourselves, we were trying to scan things with things like Opus and other models.

And I think a lot of folks have reported that if you point an existing model, including, in some cases, open weight models at a particular product and tell it to find vulnerabilities, it finds some of the stuff that Mythos is able to find in a targeted way. I think that some of the places where I think it's really interesting isn't necessarily that it's finding particular defects, it's the chaining of these things together that becomes really interesting. And so you end up with, okay, I've got a dozen, maybe the score it would get is six or something.

Not the most mind-bending vulnerability ever, not a Log4j or whatever. But by chaining these things together, you create this sort of interesting novel attack path that gets you maybe pre-auth RCE on a particular piece of software. And so it isn't necessarily that it's finding these CVSS 10 Log4j level, you need one vulnerability to exploit it kinds of thing.

It's really that composition of multiple things that you would look at each one in isolation and be like, "Eh, that's nothing," right? How would you exploit that? It's the composition of these things that's really interesting.

But even there, right, the ability to contextualize vulnerabilities is really interesting. And the first couple that sort of blew my mind about the models understanding the context in which a piece of software is running, are really interesting. " I don't know that a human looking at this code would basically ever have found this vulnerability because you have to understand the context of how a whole bunch of different moving pieces are being composed in a production context to really appreciate the sort of dynamic.

And it's wild, and I think things like Mythos are just ... that much better at it. But I think that the harness, as I think a lot of folks are starting to talk about, is a really critical aspect of it.

So not just the model, but how you run the model. And if you have a really good harness, you can often slot in a model that's not necessarily Mythos and get actually really interesting results out of it. And like I said, there have been some that we found with Opus that I was just floored by.

It was very creative and required context that a simple SaaS tool wouldn't necessarily have the context to be like, "Yeah, this is bad" in the context you happen to be deploying it in. So yeah. It's definitely super interesting times.

So are efforts to prioritize vulnerabilities and which ones to remediate kind of going to have to fall by the wayside because, well, it doesn't really matter what the rating is if I can stitch it together with a couple other things to create something more lethal? Yeah. A great example of this.

There was this fantastic, well, I think it's fantastic because I think it speaks to some of the value of what we do at Chainguard. But there's this great post by someone at Trail of Bits recently, I think it was on LinkedIn, and there was a whole blog post with a write-up. But it talked about trying to break out of a sandbox using, I think they were using the Daybreak model.

And it went through this progression where they were running on a Debian-based system, and they were challenging the model to break out of a QEMU sandbox. The first way it broke out was because the person from Trail of Bits hadn't installed the latest security updates. And so, patch your software, pull in the latest patches from your security feed, and that closed the first hole.

The second hole that it found was in libslurp, which is a networking library QEMU uses, which I think Debian had decided not to backport. And this is a place where the way we package stuff, we don't overlay our judgment on what we backport. We build with all of the patches that the upstream maintainers have decided that they want patched.

And so the person from Trail of Bits went and got a fully patched libslurp and then sent Daybreak after this thing again. Right? And then the third way it got out was through another known defect that hadn't been classified as security-related.

And yet Daybreak was able to use it to get out of a security context. And so because it wasn't security-related, it hadn't been patched in the security feeds. " But this wasn't deemed a security thing, so it never got backported.

And so again, this was a case where it was a known issue that hadn't been patched, and it was used in order to get out. And it was only after all three of those paths of known issues with QEMU and supporting components that had been closed that it even started to try and find novel attack paths out of it. And things like the attack surface of every capability in QEMU starts to become sort of an issue, the attack surface management aspect of it.

And so, yeah, I think to your point, things being classified as security issues is relevant to today's world. But the models don't care how you classified it. If it's a defect, it can try and take advantage of it and chain these things together, and things that you may not even think are security problems but are defects may actually end up being a security problem.

And so I love the post in part because the first three layers of this thing were really just about making sure that you are running the latest fully patched version of the software that you are using to keep yourselves safe. And that turns out to be, to my point about crawl, walk, run, right? Zero-day defense is running.

You need to crawl and walk first, and that starts with patching everything that is known. And don't worry about the unknown stuff until you've got your arms around the known stuff. And that is basically what we've been building for the past five years.

" So how long are we going to be in this process of, shall we say, deep cleaning of our existing vulnerabilities before we get to something that looks like we're better off than we were? I don't have a crystal ball. But I did have someone tell me they thought we had a time machine because we sort of went back five years in time and started building exactly what the world needed to sort of meet this threat.

But I think that I would prepare for this to be sort of the new normal. I think that there's folks who talk about what happens in a world where agents write vulnerability-free software. Right?

And I'm a little jaded. I see we have these solved problems around identity. Like use a hardware security key to make yourself phishing-resistant.

Use short-lived credentials instead of long-lived credentials for things like your CI workloads. A lot of the problems that underpin credential leaks are sort of solved problems, and we as an industry still have not adopted sufficiently the solutions to those problems in order to close the door on credential leaks. But even there, I think what we'll see is the models will continue to improve.

They will continue to find new things. The harnesses will continue to improve. We've talked to folks with Mythos who scanned a piece of software, and we were able to patch it through our Athena program, and they scanned it again, and it didn't find much with their harness.

But we have our own harness that we've been using to scan some of the software, and where they thought they were good, Mythos had found everything, our better harness actually found a whole bunch more stuff. And so I don't think it's just the model. I think that there's sophistication around the harness that will continuously improve in addition to the model improving.

And I think even if we get to that point where models can close the door on classes of vulnerability, like say it can find every buffer overflow in a particular piece of software. There are new classes of vulnerabilities that are found over time. I think it's like we know about buffer overflows, but then integer overflows get discovered.

Okay, so how do we make it really good at hunting that new class of vulnerability? And I think it shifts from a world where we're patching individual occurrences of vulnerabilities to closing the door on classes of vulnerabilities. Like, can we eliminate all buffer overflows?

Can we eliminate all integer overflows? There's some of the fun new ones that Google's Project Zero came up with a few years back around timing attacks where you can use the fact that processors will pre-fetch memory and maybe pull that into cache in order to see based on the performance of how things take, like use that to read memory, which is sort of a mind-blowing new class of vulnerability that the world freaked out about, or the Spectre meltdown vulnerabilities. And so I think that we can safeguard ourselves against known classes of vulnerability, and assuming we do all the work to clean up our messes.

But I think over time, if the models get to a point where they can write software that's free of known classes of vulnerabilities, it'll shift into a game of, okay, well, what new classes of vulnerabilities are there? And it becomes a little bit of a meta game. But I don't know that we will ever reach a world where it's impossible to find a new class of vulnerability.

But I suspect that if we're able to get to a point where it can write software free from known classes, that new classes will always be a problem. So how do you think this will change the way we build and deploy software? Because historically, people would be like, "Well, I'm going to devote a couple hours a month to cleaning up vulnerabilities, and I'll probably just clean up the ones that are easiest because, well, the other ones are hard and might have some open source dependency that I have no control over," et cetera.

Are we moving to a world now where there's going to be a lot more focus on continuously building some type of patch because the bad guys can reverse engineer a vulnerability now in a matter of hours? I think that's exactly right. I think that the new normal I was talking about is in some ways what our customers have sort of been preparing themselves for in adopting our existing products.

" In some sense, our modern take on building software on the Linux distribution is can we actually go from upstream releasing a patch to us having that in the form factor our customers consume at machine speed. With as much automation as we can, can we validate that works in the context of the pieces of software that we are shipping to customers as fully automated as can be. And we had actually made substantial progress on this as how we scale as a company.

And that turned out to be a great solution to this growing threat of the other side, which is leveraging agents to start to attack vulnerabilities at machine speed. And so when we were getting started, the idea of that, what agents would be able to do, and agents didn't exist. The ChatGPT moment was after we had started the company, and it's a year or so into us starting the company.

But you can now, armed with these, start to actually weaponize things at machine speed. I love the series, I think they called it "Mad Bugs" from a group called Caliph. It's a group of Pen testers that basically spent an entire month leveraging various agentic tooling to show what is possible with agents on the offensive security side.

And some of them I just absolutely love. There was a release of macOS where they pointed Claude at the before and after, and knew certain vulnerabilities were in it. And it was able, with basically zero human intervention, to produce a 100% reliable crash of a system running the unpatched software.

It can pull apart the binaries, disassemble it, look at where you added branches. It doesn't even necessarily need the source code because the bounds check's something that you could probably infer from the differences in the assembly code. And so it was able to basically figure out exactly where the check had been added, contextualize that, and figure out how to crash the unpatched software with no human involved.

And so, the skill gaps, the time gaps, the persistence that was needed previously to try and relentlessly pursue these types of vulnerabilities, figure out how to chain them together, the fact that you can now swarm agents to do that same sort of exploration, is just wild. It's pretty entertaining to just sit there and watch it sort of try and path find through pieces of software. But that's one of the ways that the harness becomes really important.

How do you set it up to sort of divide up that work and coordinate in order to find a path out? So, yeah. Moving at machine speed, I think is the new normal.

And I think that when we were getting started, we helped folks meet SLAs around compliance and patching known vulnerabilities. We were sort of optional for folks seeking those kinds of compliance links. I don't think we're really optional anymore.

I think that folks who actually want to protect against vulnerabilities and not just to meet some compliance standard, sort of need a solution like Chainguard that is delivering them patches at machine speed because they don't have quarters to patch these things anymore. They have literally hours. You can leave this thing unattended, point it at the latest release.

If someone knows you run a piece of software, some pervasive piece of software, weaponizing exploits in it has become something that is not limited to incredibly specialized experts anymore. Virtually anyone can do it. All right.

So what's your advice then to all these DevSecOps teams, CISOs, and everybody else who's trying to figure this out, but how do I approach this? Because a lot of them right now have a certain amount of deer in that headlight kind of feel about them. Yeah.

I love the sort of crawl, walk, run metaphor. You want to approach this incrementally, and yes, this thing can find scary zero-days, but like I said, that's running. I think that it starts by investing in your own processes so that you can safely and confidently pick up updates, make sure that they aren't going to break your environment.

So if you haven't, investing in a change management process that can move relatively quickly, and then slotting in solutions like ours that give you a way of picking up updates and running them through your change management processes at machine speed with your CI systems validating things with high confidence that it's not going to break your systems, puts you in a position where when there is a critical update, you can roll it out with confidence very quickly. And so I would crawl, walk, run. Invest in the processes that you need to start picking those things up.

Find a vendor that can provide you with the bits that actually patch all of the known stuff, and then you can start to get your arms around some of these zero-day type vulnerabilities if you think you are a target for those kinds of things, which a lot of folks are . There you go. Hey, folks, I think we made it clear that as the saying goes, the price of freedom is eternal vigilance.

So welcome to the future of software development. Hey, Matt, thanks for being on the show. Thanks for having me.

All right. And back to you guys in the studio.