The White House has just launched GOLD EAGLE, an AI-powered vulnerability clearinghouse. It joins the coalitions, the embargoes, and the federal deadlines. All of it stops at end-of-life, and someone has to carry the fixes the last mile.
Last week (July 14th), the White House launched GOLD EAGLE, a federal AI-powered vulnerability clearinghouse run by US departments: Treasury, DHS, and the Department of War, alongside private-sector partners. The launch release promises a coordinated system to “receive and patch cyber vulnerabilities at a speed and scale never seen before”.
I’m usually fully supportive of anything that significantly moves the needle in vulnerability discovery and remediation. The coordination proposed in this announcement is genuinely overdue. However, it’s the continued use of the word "patch" that deserves a closer look, because there is an assumption that all patches are equal or that a patch even exists for a discovered vulnerability. For an enormous slice of the software the world actually runs, one doesn’t, and no clearinghouse changes that.
This piece follows on from two earlier ones. Over on Foojay, I asked whether AI had just broken software security forever. Then here on Substack I showed what industrialised discovery looks like up close. Gold Eagle is the newest of the rescue plans proposed since then. This piece is about those plans and about their small print, because the small print matters more than the press releases.
First, the state of play for anyone joining late.
Earlier this year, an AI model found a flaw in OpenBSD’s TCP stack that had been sitting there for 27 years. The same scanning run surfaced a bug in FFmpeg’s H.264 code that had survived millions of automated fuzzing runs across 16 years. Code that has been wrong since before some of your colleagues were born, found by a machine in a single pass.
It scales, too. Mozilla pointed the same model at Firefox and found and fixed 271 vulnerabilities in release 150. The previous model generation had managed 22. Same team, same browser, ten times the findings. Only one model upgrade apart.
The wider numbers tell the same story. Anthropic’s frontier model scanned more than 1,000 open-source projects and flagged over 23,000 potential vulnerabilities; when independent security firms triaged the high and critical findings, roughly 90% were genuine.
My favourite for sheer menace and the start of the penny dropping is CVE-2026-5194 in the wolfSSL cryptography library. Found by AI-assisted analysis at Anthropic: a missing hash size check that allows forged certificates. wolfSSL is found in an estimated 5 billion devices. The coin drop that’s beginning to occur to the press and others is “how do you get a patch to all the older, unsupported ones?” Hold that thought.
The exploit side has moved just as far. On the public benchmarks, frontier models now build complete end-to-end exploits against production V8 with the security sandbox enabled, verified by the benchmark authors rather than the vendor. And on Anthropic’s own smart-contract benchmark, the exploitation capability of its models has been doubling every 0.7 months. They keep expecting that curve to flatten. It keeps straight on.
So automated and credible discovery is solved, more or less. Now it’s just width. More software is coming under scrutiny, probably quite quickly.
This moves the whole problem somewhere much more worrying. Two elephants in the room - who fixes all the old stuff? And how do fixes get out to where they are needed?
Firmware-style fix updates have always been problematic, and there is no simple (or even complex) answer for millions, if not billions, of devices. They are effectively un-patchable. There are moves to make devices (more) patchable through legislation and regulation, and I may cover that in later articles - there are some interesting nuances that could impact application development too.
For this article, I want to explore the other elephant - who fixes the old stuff then?
A vulnerability report protects nobody. Someone has to validate it, write a fix, test it, coordinate disclosure, and ship it. That someone is either an unpaid volunteer or a funded, commercially backed developer (I generalise, but you get the idea).
Of roughly 530 high or critical bugs Anthropic disclosed to open-source maintainers, only about 75 were patched in the first months. The average critical fix takes an estimated two weeks of skilled human effort. Maintainers formally asked the AI labs to slow the pace of their disclosures.
That’s the polite version of a fire brigade asking the arsonist for a tea break.
I’ve told the human-cost stories already: Daniel Stenberg closing cURL’s bug bounty under a flood of AI-generated reports, Jazzband and its 84 Python projects dissolving entirely. If you missed those, the first piece in this series has the details. The volunteers were drowning even before the good findings arrived.
The genuine AI wave, the one with 90% true positives, is bigger than the AI slop that broke them.
To the industry’s credit, the response has been fast and serious. Gold Eagle is the fourth significant structure to go up since April.
The UK’s National Cyber Security Centre moved first on the warning side. In May, CTO Ollie Whitehouse told every organisation to prepare for a “vulnerability patch wave”: a rush of updates across the whole stack as AI performs a forced correction of decades of technical debt. The advice is sound and blunt. Update by default. Automate everything you can. Patch your perimeter first.
Chainguard launched Athena in mid-June: a coalition of over two dozen organisations (Cisco, Cloudflare, JPMorgan Chase, Docker, and others) that pools AI-discovered findings, builds hardened fixes under embargo, and pushes durable fixes upstream.
The Linux Foundation followed ten days later with Akrites: a shared security incident response team for open-source maintainers, backed by AWS, Google, Microsoft, Anthropic, OpenAI and others. It also promises to act as “maintainer of last resort” for abandoned projects.
The AI labs run their own feeder programmes: Anthropic’s Project Glasswing gives vetted infrastructure companies early defensive access to its strongest model, and OpenAI’s Daybreak pushes automated scanning and patch generation into developer workflows.
And now Gold Eagle sits atop all of it: the federal clearinghouse ingesting findings from AI models, researchers, and commercial scanners, deduplicating them, and routing prioritised remediation guidance across government and critical infrastructure. It comes paired with a CISA directive that puts a 72-hour clock on the worst-case vulnerabilities.
Taken together, this is the most serious restructuring of vulnerability handling so far.
Now let’s read the small print...
Akrites describes its own process precisely: fixes flow back into each project’s original home on the maintainers’ terms. Athena’s model ends the same way, driving durable fixes upstream. And Gold Eagle’s founding promise, the one at the top of this piece, leans its whole weight on the word patch.
Think about what the maintainers’ terms are for the versions the world actually runs on.
In Java, Spring’s upstream fixes supported branches. It does not resurrect Spring Boot 2.7. The Jackson project patches current streams. AngularJS has been archived for years. The upstream policy from maintainers for end-of-life versions is, near-universally, “upgrade”.
So follow the machinery when it does everything right: the AI finds the flaw, the coalition validates it, the embargo holds, the maintainer creates the fix upstream. And then?
On the usual maintainers’ terms, one of two things happens to the EOL streams. Sometimes the CVE mentions them (unusual). You now have an unsupported stream carrying a CVE that will not, ever, ever get fixed: a compliance failure your organisation can’t remediate from the open source project.
More often, silence. There’s now a proven problem in the upstream that the bad actors (also using AI) will discover, apply to EOL versions and exploit. Your organisation has an exploitable vulnerability that your scanners are permanently unaware of.
This mechanism has been around for years. What’s changed is the scale: it’s now mainstream, common and industrialised.
The consequences are tough. The better the industry gets at fixing supported software, the more exposed the unsupported estate becomes by comparison.
Chainguard’s numbers suggest that only about 6% of one major discovery programme’s findings are currently reaching upstream maintainers at all.
A big storm swell doesn’t flatten the harbours with sea walls. It flattens the stretch of coast where nobody built one, and the taller the wave, the more the outcome depends on whether anyone is maintaining your bit of the shoreline.
The unmaintained coastline is longer than most people think. Sonatype’s supply chain research identifies 81,000 EOL package versions with known CVEs and no patches available. HeroDevs estimates the real figure is closer to 400,000, once you account for registries with patchy EOL tracking and vulnerabilities never formally disclosed.
There’s a mechanical reason the old versions are always in the blast radius. Measured across major open source codebases, the average vulnerability lives in the code for about four years before anyone finds it, closer to seven in long-lived projects like OpenSSL. A brand-new finding is usually an old flaw, already present in the versions you froze on years ago.
You can see the swell arriving. The Spring ecosystem produced 17 CVEs in the whole of 2025 and 67 in June 2026 alone, Angular racked up 21 security advisories this year, 15 of them in a single fortnight, and the seven-CVE Jackson sweep I dissected last time showed the method in miniature: AI-assisted discovery produced seven distinct findings, with zero fixes planned for the EOL streams.
The attackers were already ahead of this curve. CISA added 245 vulnerabilities to its Known Exploited Vulnerabilities catalogue in 2025. Of those, 94 dated from 2024 or earlier, a 34% jump in older flaws newly confirmed as exploited. CrowdStrike’s 2026 threat report notes a 42% rise in vulnerabilities exploited before public disclosure, and once a fix ships, attackers reverse-engineer the patch commit within hours.
Just think about it. If a fix ships for the current version and you run the old one, the public patch is a free exploit roadmap pointing at your stack. The relevant open source project is not shipping you a version of the fix. The patch wave protects the patched and (mixing metaphors) paints a target on everyone else.
Regulators have noticed, and they’re closing from both sides.
In the UK, the Cyber Essentials update that took effect in April hardened enforcement of a rule that has been in place since 2023: the 14-day window for critical patches. Missing the window now results in an automatic certification failure; the old tolerance for a couple of major non-compliances is gone, and unsupported software on an in-scope device already fails you outright. If your organisation needs Cyber Essentials for UK government work, “we’ll sort the EOL estate next year” is not an option.
In the US, CISA’s new directive replaces flat deadlines with a risk model that can demand remediation in 72 hours, and its definition of remediation is interesting: patch, isolate, segment, or uninstall. When no patch exists for your version, you’re picking from the other three. Or from the option the UK’s NCSC calls out in its own guidance: put the software back under vendor support.
And if 72 hours sounds achievable, Verizon’s 2026 breach report says otherwise: only 26% of the vulnerabilities on CISA’s exploited list were fully remediated in 2025, down from 38% the year before, with a median fix time of 43 days. The supported world is missing the deadlines too. Now remove the patch entirely.
The EU’s Cyber Resilience Act really kicks in this September for anyone shipping products with digital elements into the EU, with a 24-hour reporting clock included.
And the cyber insurers are already running their own privatised preview of the whole regulatory regime at every renewal.
1 Inventory support status, properly.
Do this today. Really.
Most scanning tools flag known CVEs and have no opinion on whether anyone would ever fix them; as we saw with the Jackson advisories, plenty are behind on the CVEs, too. You need to know which of your dependencies have a living upstream. A dedicated end-of-life dataset like the one from HeroDevs helps close that gap. The details of what’s covered are here.
Look, it’s free. Just run the scan.
(If you want, you can add the CLI or its equivalents into your CI/CD system.)
2 Adopt update-by-default where the upstream is alive. The NCSC is right about this. Automate the boring patches; spend your humans on the hard ones. The wave is entirely survivable for supported software; that’s rather the point. I know this is hard, but keeping current is the primary survival option, followed swiftly by commercial EOL support. Unmaintained software is turning into a commercial and legal problem.
3 Make an explicit decision for every EOL dependency. Decide: Migrate now. Self-patch (which means forking it, owning it forever, and dealing with the tsunami of CVEs as they occur). Or buy commercial support such as Never-Ending Support for the EOL versions.
Trying to isolate the system and accept the risk in writing is possible, but Log4Shell showed us how vulnerabilities can be triggered in non-internet-facing, firewalled systems.
Each is right in the right situation. Drifting along with none of them is the only wrong answer, and it’s the default in most organisations. Declaration of interest: I work for HeroDevs, so of course I’d point to option three :-). The NCSC’s guidance says legacy systems must be replaced or returned to vendor support, and they don’t work for us.
4 Compress your response-time assumptions. Whatever your patch SLA was in 2024, it’s wrong now. Plan for critical fixes needing deployment in days, and for CVE disclosures arriving in clusters rather than a steady drip. Sixty-seven Spring CVEs in a month. Fifteen Angular advisories in a fortnight. Seven Jackson findings in a day. That’s the new shape.
Let’s hope that the industry has finally begun to build a genuinely better system for fixing software vulnerabilities. Clearinghouses, coalitions, embargoes, federal clocks: the supported software world is getting the attention it needs to keep it safer, faster.
Everything outside that world, though, is getting more dangerous at the same rate, and for the same reason. The machines reading the world’s code do not check the support status first.
Your job, before this swell peaks, is to make sure everything you run sits inside the maintained world, one way or another. Migrate it, support it, or really fence it off. Every upstream fix needs someone to carry it the EOL last mile, and for your stack that someone is you, a vendor, or nobody.
Having governments declaring ‘done’ too quickly is a real possibility - the EOL / Non EOL divide is significant. There are far more EOL versions than supported ones, and the percentage gets worse every day. Retiring EOL software from public repos might help, but I’m sure you can see the downsides. More likely, we’ll see more and more commercial efforts to provide EOL support, but that’s inevitably going to change the dynamics of open source. There are already vendors hinting at using vulnerability fixes as a commercial differentiator - buy support, and you’ll get fixes ahead of the (free) open source variant. Ouch.
We’re still back to the same thing - you need to focus on creating reliable, automated build and test systems (with a good number of tests) that allow you to easily keep your dependencies (and build tools and operating systems) current.
If you’re using AI to generate code, you’re probably realising you need a better QA system than ever before to keep up. It’s not much of a step to realise that the systems you need to manage the productivity offered by AI can be used to keep your systems patched and safe.
The takeaway is that this direction is no longer a nice-to-have. Good software engineering processes are essential for the future, so now’s the time to start getting that in-plan.
Sources for every statistic in this piece were checked against primary sources in July 2026:
Anthropic, Project Glasswing first-month update (scan scale, triage rates, OpenBSD and FFmpeg finds, Mozilla results, maintainer disclosure figures)
Anthropic’s published exploit evaluations (V8 exploits, 0.7-month doubling)
Athena launch and Chainguard’s programme reporting (including the 6% figure)
CISA’s KEV catalogue with Cyble’s 2025 analysis (245 additions, 94 older flaws, 34% rise)
Verizon 2026 DBIR figures via CISA’s “Patch Smarter, Not Harder” (26% remediated, down from 38%; 43-day median)
Alexopoulos et al., “How Long Do Vulnerabilities Live in the Code?”, USENIX Security 2022 (four-year average lifetime)
HeroDevs CVE tracking: Spring, Angular, and the vulnerability directory
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.