Old code was quiet, not safe.

A team reviews its list of systems, sorted by incidents in the last five years. The noisy ones are at the top, with their outages and their patch notes. At the bottom sit the quiet ones: a file-transfer server nobody has touched since it was installed, a network appliance from a vendor that was bought and stopped shipping updates, an internal export tool whose author left years ago. They are rated low risk, because nothing has gone wrong. The list is invented for this dispatch. Then a headline says a machine found a bug that had survived 27 years in software built to be careful.

Last Tuesday, April 7, Anthropic said that a model it does not plan to release generally, Claude Mythos Preview, had found what it described as "thousands of high-severity vulnerabilities, including some in every major operating system and web browser." It set up Project Glasswing to give a group of large technology companies and more than 40 other organizations that maintain critical software access first, for defensive work, with up to $100 million in usage credits.¹ The examples it could disclose were old. One was a 27-year-old flaw in OpenBSD, an operating system known mainly for its security. Another was a 16-year-old flaw in FFmpeg, in a line of code that, by Anthropic's account, automated testing tools had exercised five million times without catching the problem. Both have been reported and fixed.¹² The same day, according to reports citing unnamed sources, the Treasury Secretary and the Fed Chair called bank chief executives to a meeting about the risk.³

My argument is that most organizations rate software by years without a problem, when what protects them is someone who can fix it. A system that has been quiet for a decade has not been proven safe. Part of the quiet was the price of looking, because finding a deep flaw took rare expertise and a lot of time. If that price has fallen, quiet stops being evidence. What did not get cheaper is producing a fix and getting it onto the machines that need it.

Finding got cheaper. Fixing did not.

Anthropic's own description of the change is about cost. Flaws go unnoticed for years, it wrote, because finding and exploiting them required expertise held by only a few people, and that with the latest models the cost, effort and expertise needed to find and exploit them have all dropped sharply.¹ Its technical post added that turning a published fix into a working attack, which once took a skilled researcher days to weeks per bug, now happens much faster.²

The other side of the ledger moved much less. Anthropic says it sends findings through human reviewers before disclosing them, so as not to overwhelm maintainers, and that as a result fewer than 1 percent of the potential vulnerabilities it had found had been fully patched by their maintainers when it published. By its count, over 99 percent were still unpatched.² Maintainers were already describing the load. Daniel Stenberg, who leads the curl project, wrote recently that low-quality AI reports had stopped arriving, replaced by "an ever-increasing amount of really good security reports."⁴ The Internet Bug Bounty program said it would stop paying awards at the end of March because the balance between findings and the capacity to fix them had shifted, as quoted by The Register.⁴ In an opinion column there on Friday, Chainguard's Dan Lorenc was quoted as saying projects and enterprises probably are not ready for the influx of real vulnerabilities and patches.⁵

Count who can fix it

Old code is not the problem. Old code with nobody behind it is. For each system, the question that matters is whether a maintainer, a vendor under contract or an internal team can produce a fix, and how long that fix takes to reach production. Anthropic itself named the hardest case in its advice to defenders: an application whose developer you acquired but no longer support.² Every organization has some version of it. A vendor that can be bought and shut down is one reason this site argued in March that you have to be able to leave. Last week's dispatch, A familiar name can deliver unfamiliar code, was about trusting a name; this one is about whether anyone behind the name can still answer.

Keep the claim modest

These figures are Anthropic's, and almost none can be checked yet. The company says it will publish details once fixes are out, and it is promoting a product and a program; it plans to charge participants once the credits run out.¹ Heidy Khlaaf of the AI Now Institute warned on X, as reported by NBC News, against taking the claims at face value without false-positive rates and clearer accounts of the human review.⁶ The UK AI Security Institute's evaluation, published yesterday, found a real step up, including the first model to complete its 32-step simulated corporate network attack, in 3 of 10 attempts. But its test ranges had no active defenders, so, in the institute's words, "we cannot say for sure whether Mythos Preview would be able to attack well-defended systems."⁷

The argument here does not depend on the model being as good as advertised. It depends only on looking having become cheaper, which the maintainers' inboxes show on their own. This is not an argument that old software is bad: long-lived systems often earn their keep, and age by itself is not a flaw. It is not a prediction that attacks will rise on any date, a verdict on Anthropic's release decision, or advice to rip out legacy systems. It is narrower. If quiet was ever your evidence of safety, it has stopped being good evidence.

What to check this month

• (a) Add an owner column, and sort by it. For each system and major component, write down who produces fixes: a maintainer, a vendor under contract, an internal team, or nobody.
• (b) Decide each "nobody" row. For acquired or silent vendors, products past end of support, tools whose authors left and appliances you cannot patch, choose: replace, isolate, pay for support, or accept the risk in writing, signed by someone who can accept it.
• (c) Time the route. Measure how long a published fix takes to reach production, and treat security updates to dependencies as urgent rather than routine, as Anthropic advises.² Confirming the service still works afterward is its own step, covered in The patch is not the finish line.
• (d) Plan for more volume. Expect more advisories and out-of-cycle releases, check that the people who triage them can absorb a surge, and fund or contribute to the open-source projects you would most hate to lose.

Back to the list. Sort it again, this time by the new column. The quiet systems at the bottom move to the top, not because anything went wrong with them, but because three of them have no one who could answer if something did.