The flood is coming and the pipes were already full

The flood is coming and the pipes were already full - View all articles Dan Lorenc Co-founder and CEO Chainguard Dan Lorenc Co-founder and CEO An update on Athena, and some unsolicited predictions on what's coming next On Saturday, Dario Amodei published We Must Pace the Frontier. I agree with him. Go read it if you haven't. I've spent the summer looking at what these models find, and the gap he describes between what they can do and what the rest of us are ready for is the one I've been staring at since May. The hardest piece of his plan is the one that asks governments to coordinate. They're in a difficult spot: regulate too little and a US company accidentally builds the weapon, regulate too much and it gets built somewhere else, and open source isn't governable either way. Where governments can act is on consumption: not what the models can do, but what happens to what they find. Who gets a vulnerability first, how fast a fix reaches the people running the code, whether the operators who can't move on an attacker's timeline get a head start. That's what Gold Eagle is. It matters because of where the risk actually lands. The danger in Dario's essay isn't a model in a lab. It's a model pointed at the power grid, the water system, the hospital network, all of it running on decades of software with the same exploitable design. The frontier is where the capability comes from. Consumption is where it does damage, and that's the end you can still defend. So pacing has two ends. The frontier end is Dario's and the government's problem, and it's hard. The consumption end is ours: the disclosure processes, the patch pipelines, and the software itself, everything that has to absorb what the models produce. Pacing buys time on the frontier end. This post is a status report on how we're spending it, in three parts: We start disclosing Athena findings this month, beginning with 50. We joined Anthropic's Project Glasswing and are finding our own vulnerabilities, and I'll show you what that looks like. We built infrastructure to make both possible, and we're going to open it up. The short version: I'm more worried than I was in May, and more sure about what to do about it. The first 50 Athena has been taking in findings since June. The intake numbers are public: more than 40,000 findings, 42% of them critical or high, across more than 500 projects, with more than 2,000 patches produced. What hasn't been public is how much of that we've been sitting on. Generating fixes was never the bottleneck. Disclosing them responsibly, at a scale nobody has ever tried, is. On September 28, we start. We're beginning with about fifty, and none of them are the scary ones. That's deliberate. The frightening findings, the live pre-auth RCEs, go through Akrites on embargo, which I'll come back to. The first 50 are low-stakes on purpose: a small batch to get the flywheel turning and find out what breaks before the thousands behind them hit it. All 50 are silent fixes: vulnerabilities already fixed at head, sometimes years ago, where nobody ever filed a CVE. Your scanner has nothing to say about them, and the old versions are still running everywhere. This pattern showed up in Athena almost immediately. A big share of what the models find only affects old versions, because the models scan what's actually deployed, and what's deployed is old. Two systems fail at once with silent fixes, and neither is anyone's fault. Upstreams typically won't merge fixes to old versions, and they're right not to: the code was rewritten years ago, there's no branch to merge into, and "upgrade" is the correct answer. And the advisory layer has nothing to work with, because CVEs don't get filed for things already fixed at head. It's the one class of finding where acting doesn't step on anyone else's process, because there isn't one. For each one, where the project has no path for accepting fixes to old versions, we're doing three things. We publish the patch. Plain .patch files, in a public Chainguard repo that says exactly what it is on the tin, under the project's original license. This is deliberately not a maintainer-of-last-resort move. We have plans for that, and I'll get to them below, but they're for projects nobody maintains anymore. These are active projects that already fixed the bug at head. We're not forking anything, not claiming stewardship, not creating a new namespace, and not inviting anyone to build from it. It's a place to put patches for the people who can't upgrade yet, and nothing more. The durable fix is still upgrading, but this step reflects today's reality, where most of what's deployed isn't upgraded. We publish the advisory. A Chainguard OSV feed, with fully enumerated affected version ranges and the exact symbols affected. Not "some 2.x releases, probably." Athena partner scanners are integrating with it now, so these show up where your team already looks. We ship the fix. Patched versions land in Chainguard Libraries for every Chainguard customer the moment the advisory goes live. We're not planning to contact maintainers ahead of each of these. They already deal with more noise than anyone should, and we don't want to add to it, least of all for bugs they fixed years ago. If you maintain a project and you'd rather hear from us in advance going forward, or if you have any other concerns about how this touches your project, let us know at cna@chainguard.dev, and we'll happily work with you. We're becoming a CNA A silent fix used to be mostly harmless. Nobody had written the bug down, and finding it from a fix commit took real expertise and real time. That's over. A model can go from a public fix commit to a working exploit against every version that never got the fix in an afternoon. The finding exists whether we publish it or not. The only question is whether defenders get a copy, too. Once people know about a bug, the world needs a signal to upgrade, and the signal the world already has is the CVE. Scanners, KEV, and every compliance regime key on it. Silent fixes had none. So, in support of the Gold Eagle initiative, and in partnership with CISA, Chainguard is in progress to become a CVE Numbering Authority, scoped to open source vulnerabilities processed through Athena, where upstream has already fixed the flaw without an identifier, or where no maintainer is left to assign one, and no more specific CNA covers the project. The uncomfortable part: this will put new noise in your scanners. Old versions that scanned clean last week will light up. That's better than no noise and a breach. Silence in that channel was never safety, it was just nobody having looked yet. We also go to great lengths to keep each advisory as narrow as it can be. Every entry is enriched with the exact introduced and fixed ranges across every release branch, not a single version floor, and carries module, class, and function level detail on what's actually affected. That's what reachability scanners need to filter out the false positives for your codebase, so the noise you do see should be the noise that matters. The narrowness is the point. We assign only where there is no upstream to defer to. If a vulnerability exists at the latest version and the maintainer is reachable, the project's own CNA assigns it, and we are the reporter, never the assigner. Every assignment clears the same gates: a reproduced finding, never raw model output; a defensible commit range; affected versions in real use; the maintainer notified with a response window; and withdrawal if the maintainer shows us we're wrong. Projects that become their own CNA leave our scope. This is a transitional role, not a territorial one. Where the rest goes The map for everything else is simple. If a vulnerability exists at the latest version and the maintainer is reachable, that's Plan A, and it runs through Akrites, the shared disclosure body the Linux Foundation launched in June, and that we helped found. If it exists at latest and the project is unmaintained, that's maintainer-of-last-resort territory, and we're working with other Akrites members to stand that up inside Akrites, where it belongs. And Gold Eagle, the federal clearinghouse that came out of June's executive order, is the layer that gets prioritized findings in front of the critical infrastructure operators who can't move on an attacker's timeline. We spent a good part of the summer waiting on both of those and helping build them. Akrites goes operational this month. I'll be straight about the tradeoff: one shared incident response team across dozens of organizations is slower at first than everyone acting alone. That's the cost of choosing "maintainers deal with one trusted counterpart" over "maintainers deal with thirty strangers," and we'd make it again. The disclosure and upstreaming numbers get published either way, pretty or not. A model found all of it in an afternoon The second reason I'm worried is less about process and more about what I've seen. We joined Anthropic's Project Glasswing. Lots of organizations have, at this point, roughly 200 across 15-plus countries, so our joining isn't news on its own. What matters is what it means for Athena: we now have Mythos, and we're running it against the software we build and ship. Here's the shape of one run, and I've picked it because it's the least reassuring result we have. One widely used open source project. One run, about six hours. The harness came back with more than a dozen validated vulnerabilities, most of them pre-authentication remote code execution, reachable with no credentials and no operator action. Every one was reproduced three times in a clean VM before it counted, under the rule I'll describe in a minute: the model doesn't get to claim a finding, the host has to reproduce it. This is not an abandoned package. It's one of the most heavily scanned, tested, and fuzzed projects in the ecosystem, code that has survived years of expert review and relentless fuzzing. A model found all of it in an afternoon. These go through Akrites like everyone else's findings, and I'm not going to say more about the specific project here than that. Here's what I'll say instead. Watching what these models find, and how long it takes a fix to reach anyone once they find it, is what worries me. It isn't the models themselves. It's the race between two clocks. On one, the industry is trying to absorb a short-term rush of findings through disclosure processes that were already behind. On the other, attacker capability is advancing toward the point where compromising critical infrastructure at scale becomes cheap. Right now, the second clock is running faster than the first, and I don't see anything that closes that gap on its own. Sandboxes and sandboxing Which is the other reason the sandbox matters. Producing a finding like the one above means building and detonating a working exploit against real code, over and over, driven by an agent nobody is watching in real time. That is dangerous to run, and this summer has been a run of examples of people running it unsafely. The incident Dario built his essay around, OpenAI's agents breaking out of a cyber evaluation and ending up inside Hugging Face's production infrastructure, started with a zero-day in the package cache the agents had been given. Package infrastructure is what we build, so that one landed close to home. Pillar Security spent a week in July publishing sandbox escapes across Cursor, Codex, Gemini CLI, and Antigravity, and the finding that tied them together was that the agent almost never broke the sandbox head-on. It wrote a file it was allowed to write, and something trusted outside the box ran it later. None of these was a problem of insufficient sandboxes. They were a problem of insufficient sandboxing: the boundary existed, and everything interesting happened in the gaps around it. Denylists don't contain any better than containers do. Everything Athena does, from developing an exploit to proving a patch closes the hole, runs inside a microVM, the same primitive our package builds, image builds, and CI have run on for years. Matt wrote up the architecture in July. The short version: every job gets a hardware-virtualized guest with its own kernel and a root filesystem built from scratch, egress is enforced at the hypervisor and allowlisted to package registries and nothing else, the first forbidden connection destroys the VM, and no credentials ever enter the guest. And because a shared primitive multiplies the blast radius of any weakness, we point AI agents at the sandbox itself with instructions to break it. Every finding lands as a failing test first, then the fix. The harness starts with a person The harness that runs inside those sandboxes is the part I find most interesting, and it starts with a person. Ian Beer spent about six months writing a zero-click iOS exploit chain, and if you read the write-up as a search, you can see the shape of it: poke at a target, go deep, hit a dead end, back up, eventually connect enough dots to reach a working exploit. No human holds six months of that in working memory. He kept it in notes and pulled back the slice he needed each session. His notebook was the environment. That's what we built, sharded across many agents in parallel: a tree search where every agent starts fresh with a scoped surface and a distilled trail of what's already known, and continuity lives in durable findings rather than anyone's context window. The rule I care most about is that the host casts the vote, never the model. A finding only counts if the host can replay it against a clean instance: the check fails before, the replay runs, the check passes after. Nothing enters the record until reality agrees, and that one rule is most of why the false positive rate is as low as it is. A few things we learned building this, if you're working on something similar: Fresh context, bounded job. Every agent starts clean with a scoped surface. Continuity lives in findings written for a stranger, not a transcript. Every write gated on evidence. Without a precondition, a postcondition, and a host-runnable replay, it doesn't enter the record. Research steers, it doesn't prove. It decides where an agent looks next and never counts as a finding. Record dead ends as findings, too. A false positive collides with reality and starves on its own. A false negative is silent, permanent, and the failure that actually costs you the deep bugs. Taste beats fleet size. In a search like this, the model's per-step judgment about where to look is the base of an exponent, and parallelism only shows up inside a logarithm. You cannot buy your way out of worse taste with more agents. That's the concrete, non-marketing reason we wanted Mythos, and why Glasswing matters more than how many agents you can run. Put the pieces together, and the loop closes. Find, contain, fix, ship. All of it on one primitive. What we built to do this, and what we're opening up None of this was possible on off-the-shelf infrastructure. Over the last year, we rebuilt our factory on three new primitives, and every one of them started as something we needed for ourselves before it was anything we could sell. The sandbox is the microVM you just read about: the isolation boundary that lets us run untrusted code and hostile agents without the blast radius reaching anything that matters. The harness is the search that runs inside it, the thing that found those pre-auth RCEs. And the third is CI as a function: our own fleet stopped sending code out to a CI system a year ago. The checks run in the loop, and changes arrive already proven, at more than ten times the CVE volume we were handling before. We built all three because we had to; we've been running our entire operation on them, and over the coming quarters, we're going to start opening them up directly. If you are running untrusted AI workloads, or trying to find real vulnerabilities in your own code, or drowning in CI that tells you less than you'd like, these are the tools we reached for. Soon you'll be able to reach for them too. So what is the endgame here? Here's the unsolicited prediction. Everyone is worried about Mythos zero-days right now, and almost nobody was keeping up with ordinary CVEs before any of this started. The median enterprise is months behind on patches that have had fixes, advisories, and scanner coverage for years. That's the system we're about to pour thousands of new findings into. Faster disclosure and faster patching only help the people who can move on them, and most of the world can't move at the speed a model sets. If you take one thing from this post, take this: the flood is coming, and the pipes were already full. Which is why none of the above is the finish line. Everything in this post makes us faster, and all of it accepts a losing premise: that the goal is to keep pace with a discovery rate set by frontier models. The vulnerability classes those models exploit aren't defects in today's software. They're its design. Memory corruption, deserialization, injection, confused deputies: consequences of how the stacks under every enterprise application were built. You cannot patch your way out of an architecture. So the endgame is new foundations: a stack built secure by construction, where the dominant vulnerability classes can't be written in the first place, filling the role Spring Boot fills today, across every enterprise language, underneath the frameworks and the registries they pull from. For forty years, migration costs protected every incumbent platform. Nobody rewrote the COBOL because nobody could afford to. Agents just collapsed that cost. We're working on this, and I'll say more when there's more to say. Why us: we see the world's pre-disclosure findings before almost anyone, so we know which bug classes matter, and we have the one tool that can prove a foundation removed them. Point Mythos at it before you ship, and you know. Dario is right that pacing buys time, and everything above is how we're spending it. But a paced frontier only matters if the software underneath survives the frontier we already have. If the dominant vulnerability classes can't be written, the critical infrastructure built on them can't be broken by them, and a frontier model in the wrong hands has far less to reach. Pacing limits the risk by slowing the capability. Foundations limit it by taking away the target, and that's the only version of this I can see that ends the treadmill instead of running faster on it. The Programmer's Credo says we do these things not because they are easy, but because we thought they would be easy when we started. This is the first one where I didn't even think that. We're doing it anyway. If you maintain a project any of this touches, or if you're finding vulnerabilities, join at chainguard.dev/athena. And if any of this sounds like something you want to build, we're hiring. Share this article Related articles - security Athena spotlight: Black Duck on the importance of flagging zero-days at scale - security How financial services companies can modernize their software supply chain - security Proven, not promised: Chainguard Containers achieves SLSA Build Level 3 - security The keyv and cacheable npm Supply Chain Attack: Inside the Mini Shai-Hulud Campaign - security Why AI-assisted attacks made software supply chain security its own category - security Why zero CVEs matters in mobile airgapped deployments