{"id":2195,"date":"2026-11-06T12:14:55","date_gmt":"2026-11-06T12:14:55","guid":{"rendered":"https:\/\/cybercolombia.co\/index.php\/2026\/11\/06\/the-flood-is-coming-and-the-pipes-were-already-full-cyberdefensa-mx\/"},"modified":"2026-11-06T12:14:55","modified_gmt":"2026-11-06T12:14:55","slug":"the-flood-is-coming-and-the-pipes-were-already-full-cyberdefensa-mx","status":"publish","type":"post","link":"https:\/\/cybercolombia.co\/index.php\/2026\/11\/06\/the-flood-is-coming-and-the-pipes-were-already-full-cyberdefensa-mx\/","title":{"rendered":"The Flood is Coming And The Pipes Were Already Full \u2013 CYBERDEFENSA.MX"},"content":{"rendered":"
\n

An update on Athena, and some unsolicited predictions on what\u2019s coming next<\/em><\/p>\n

On Saturday, Dario Amodei published We Must Pace the Frontier<\/em>. I agree with him. Go read it if you haven\u2019t. I\u2019ve 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\u2019ve been staring at since May.<\/p>\n

The hardest piece of his plan is the one that asks governments to coordinate. They\u2019re 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\u2019t 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\u2019t move on an attacker\u2019s timeline get a head start. That\u2019s what Gold Eagle is.<\/p>\n

It matters because of where the risk actually lands. The danger in Dario\u2019s essay isn\u2019t a model in a lab. It\u2019s 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\u2019s the end you can still defend.<\/p>\n

So pacing has two ends. The frontier end is Dario\u2019s and the government\u2019s problem, and it\u2019s 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\u2019re spending it, in three parts:<\/p>\n

    \n
  1. We start disclosing Athena findings this month, beginning with 50.<\/li>\n
  2. We joined Anthropic\u2019s Project Glasswing and are finding our own vulnerabilities, and I\u2019ll show you what that looks like.<\/li>\n
  3. We built infrastructure to make both possible, and we\u2019re going to open it up.<\/li>\n<\/ol>\n

    The short version: I\u2019m more worried than I was in May, and more sure about what to do about it.<\/p>\n

    The first 50<\/h2>\n

    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\u2019t been public is how much of that we\u2019ve been sitting on. Generating fixes was never the bottleneck. Disclosing them responsibly, at a scale nobody has ever tried, is.<\/p>\n

    On September 28, we start. We\u2019re beginning with about fifty, and none of them are the scary ones. That\u2019s deliberate. The frightening findings, the live pre-auth RCEs, go through Akrites on embargo, which I\u2019ll 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.<\/p>\n

    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\u2019s actually deployed, and what\u2019s deployed is old.<\/p>\n

    Two systems fail at once with silent fixes, and neither is anyone\u2019s fault. Upstreams typically won\u2019t merge fixes to old versions, and they\u2019re right not to: the code was rewritten years ago, there\u2019s no branch to merge into, and \u00abupgrade\u00bb is the correct answer. And the advisory layer has nothing to work with, because CVEs don\u2019t get filed for things already fixed at head. It\u2019s the one class of finding where acting doesn\u2019t step on anyone else\u2019s process, because there isn\u2019t one.<\/p>\n

    For each one, where the project has no path for accepting fixes to old versions, we\u2019re doing three things.<\/p>\n

    We publish the patch.<\/strong> Plain .patch files, in a public Chainguard repo that says exactly what it is on the tin, under the project\u2019s original license. This is deliberately not a maintainer-of-last-resort move. We have plans for that, and I\u2019ll get to them below, but they\u2019re for projects nobody maintains anymore. These are active projects that already fixed the bug at head. We\u2019re not forking anything, not claiming stewardship, not creating a new namespace, and not inviting anyone to build from it. It\u2019s a place to put patches for the people who can\u2019t upgrade yet, and nothing more. The durable fix is still upgrading, but this step reflects today\u2019s reality, where most of what\u2019s deployed isn\u2019t upgraded.<\/p>\n

    We publish the advisory.<\/strong> A Chainguard OSV feed, with fully enumerated affected version ranges and the exact symbols affected. Not \u00absome 2.x releases, probably.\u00bb Athena partner scanners are integrating with it now, so these show up where your team already looks.<\/p>\n

    We ship the fix.<\/strong> Patched versions land in Chainguard Libraries for every Chainguard customer the moment the advisory goes live.<\/p>\n

    We\u2019re not planning to contact maintainers ahead of each of these. They already deal with more noise than anyone should, and we don\u2019t want to add to it, least of all for bugs they fixed years ago. If you maintain a project and you\u2019d rather hear from us in advance going forward, or you have any other concerns about how this touches your project, let us know at cna@chainguard.dev and we\u2019ll happily work with you.<\/a><\/p>\n

    We\u2019re becoming a CNA<\/h2>\n

    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\u2019s 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.<\/p>\n

    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 already fixed the flaw without an identifier, or where no maintainer is left to assign one, and no more specific CNA covers the project.<\/p>\n

    The uncomfortable part: this will put new noise in your scanners. Old versions that scanned clean last week will light up. That\u2019s better than no noise and a breach. Silence in that channel was never safety, it was just nobody having looked yet.<\/p>\n

    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\u2019s actually affected. That\u2019s 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.<\/p>\n

    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\u2019s 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\u2019re wrong. Projects that become their own CNA leave our scope. This is a transitional role, not a territorial one.<\/p>\n

    Where the rest goes<\/h2>\n

    The map for everything else is simple. If a vulnerability exists at the latest version and the maintainer is reachable, that\u2019s 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\u2019s maintainer-of-last-resort territory, and we\u2019re 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\u2019s executive order, is the layer that gets prioritized findings in front of the critical infrastructure operators who can\u2019t move on an attacker\u2019s timeline.<\/p>\n

    We spent a good part of the summer waiting on both of those and helping build them. Akrites goes operational this month. I\u2019ll be straight about the tradeoff: one shared incident response team across dozens of organizations is slower at first than everyone acting alone. That\u2019s the cost of choosing \u00abmaintainers deal with one trusted counterpart\u00bb over \u00abmaintainers deal with thirty strangers,\u00bb and we\u2019d make it again. The disclosure and upstreaming numbers get published either way, pretty or not.<\/p>\n

    A model found all of it in an afternoon<\/h2>\n

    The second reason I\u2019m worried is less about process and more about what I\u2019ve seen. We joined Anthropic\u2019s Project Glasswing. Lots of organizations have, at this point, roughly 200 across 15-plus countries, so our joining isn\u2019t news on its own. What matters is what it means for Athena: we now have Mythos, and we\u2019re running it against the software we build and ship.<\/p>\n

    Here\u2019s the shape of one run, and I\u2019ve picked it because it\u2019s the least reassuring result we have.<\/p>\n

    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\u2019ll describe in a minute: the model doesn\u2019t get to claim a finding, the host has to reproduce it. This is not an abandoned package. It\u2019s 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\u2019s findings, and I\u2019m not going to say more about the specific project here than that.<\/p>\n

    Here\u2019s what I\u2019ll 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\u2019t the models themselves. It\u2019s 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\u2019t see anything that closes that gap on its own.<\/p>\n

    Sandboxes and sandboxing<\/h2>\n

    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\u2019s agents breaking out of a cyber evaluation and ending up inside Hugging Face\u2019s 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\u2019t contain any better than containers do.<\/p>\n

    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.<\/p>\n

    The harness starts with a person<\/h2>\n

    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.<\/p>\n

    That\u2019s 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\u2019s already known, and continuity lives in durable findings rather than anyone\u2019s 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.<\/p>\n

    A few things we learned building this, if you\u2019re working on something similar:<\/p>\n