The 6% Problem: AI Finds Flaws at Machine Speed and the World Fixes Them at Human Speed
One disclosure programme for AI-found vulnerabilities reported a 6% fix rate. Run that number against a typical dependency tree and the Cyber Essentials clock, and every frontier release date becomes a patch surge most UK firms are not staffed for.
By late May 2026, roughly 6% of the vulnerabilities disclosed through one AI-discovery programme had been fixed. The figure comes from testimony to the US House Homeland Security Committee, which asked openly whether disclosure systems can keep pace with each model release. It is the most useful number yet published on how AI is changing vulnerability discovery and patch management, because it converts a vague anxiety into arithmetic you can run against your own systems. This article runs it.
How is AI changing vulnerability discovery and patch management?
Coordinated disclosure was engineered for scarcity. A researcher finds a flaw, reports it quietly, the vendor gets a fixed clock (90 days, give or take) to ship a fix, and then the advisory goes public. Every part of that machine assumes discovery arrives as a trickle.
Machine-scale discovery breaks those assumptions simultaneously. The Cloud Security Alliance has examined vendor claims that a single model surfaced thousands of previously unknown vulnerabilities, including flaws that had sat in heavily audited open-source code for decades. The CSA could not independently verify the capability claims, so treat the specific totals as unproven. The 6% remediation figure needs no such caveat: whatever the true discovery rate turns out to be, the fixing rate is documented, and it is dismal. Discovery is being automated. Fixing is not.
How big is your share of the backlog?
Start with the shape of a modern dependency tree. A study of the npm ecosystem presented at USENIX Security found that installing an average package means implicitly trusting 79 other packages and 39 maintainers. A mid-sized product with a few dozen direct dependencies is therefore standing on several hundred to a thousand distinct components, most of which its developers have never read.
Now put numbers on a disclosure wave. Assume, conservatively, that a machine-scale disclosure event touches 2% of a 1,000-component tree: twenty affected components. At the remediation rate reported in the House testimony, roughly one of those twenty will have an upstream fix waiting on release day. The other nineteen are yours to mitigate, isolate or replace.
The UK gives that workload a deadline. Cyber Essentials requires critical and high-risk security updates to be applied within 14 days, and certification is a standing condition of many public-sector contracts. Nineteen component-level mitigations in fourteen days means shipping 1.4 a day, sustained for a fortnight, on top of business as usual.
Compare that with measured reality. Veracode's analysis of third-party code found that 79% of libraries are never updated after being added to a codebase, so the honest baseline throughput for most teams is close to zero. If 2% feels aggressive, run the sum at 0.5%: five components in a fortnight still exceeds what a team shipping one dependency update a week can absorb. The conclusion survives any defensible input. A modest disclosure wave outruns typical patch capacity by an order of magnitude.
Who gets patched before you do?
A lab holding a mass of unpublished flaws must tell someone before it tells everyone. Sitting on them is indefensible, dumping them on the public is worse, and briefing thousands of affected projects quietly is impossible. The rational move is to pre-brief a small circle: the largest platforms, with security teams big enough to absorb a confidential firehose. That is triage, and it is also, by any commercial definition, a membership tier. The interval between the circle's private patching and public model availability is a scheduled exposure window with a roughly predictable start date and a guest list you cannot influence.
Outside the circle, the load lands on the least resourced people in the stack. The Linux Foundation's Census II of free and open-source software found the most widely used libraries resting on a small number of maintainers, many unpaid. There is no on-call rota for a volunteer who looks after a twenty-year-old parsing library, and no consortium will pre-patch your transitive dependencies. The 6% figure is what discovery scaling like software looks like while repair still scales like people.
What does a release-day patch surge model look like?
Treat announced frontier-model releases the way facilities teams treat storm forecasts: dated events that trigger a rehearsed response. The model has four parts.
Ownership. The surge belongs to whoever owns the deployment pipeline, typically the head of engineering or IT operations. Security's job is triage and ranking; engineering's job is shipping. A surge plan owned by a team that cannot deploy is just a document.
A measured baseline. Count the dependency updates your team tested and deployed per week over the last quarter, from change records rather than memory. That number is your real surge capacity, and knowing it belongs in your technical strategy alongside a dependency inventory that flags the components nobody upstream will ever fix for you.
Thresholds. Size the surge with the arithmetic above: tree size, times an assumed touch rate, times the 94% of findings you should assume arrive unfixed, divided by fourteen days. If the result sits inside your measured capacity, rehearse and move on. If it exceeds capacity, and for most mid-sized firms it will, pre-agree mitigations that do not depend on patching: virtual patches at the gateway, network isolation for at-risk components, feature-flag kill switches, and a ranked list of the twenty dependencies you would defend first. Designing components so they can be cut off without taking the product down is the same discipline we argue for in securing agentic systems.
UK consequences, written down. A lapsed Cyber Essentials certificate can disqualify you from public-sector work. An exploited flaw that touches personal data starts the ICO's 72-hour reporting clock. Cyber insurers ask about patch cadence at every renewal. Those three consequences belong in the procurement papers before you build anything on a frontier model, which is the unglamorous half of AI readiness.
The pre-patch circle will keep its list and the release dates will keep coming. Of every number in this piece, measured patch throughput is the only one you control, and the next release date is already in someone's diary. Measure yours this week.
Questions people ask
What is a vulnerability disclosure window, and why is it becoming more dangerous?
It's the gap between a flaw being reported privately and the details becoming public. Historically it protected users while a patch shipped. When an AI model both generates the findings and becomes publicly available on a known date, the window becomes a countdown to the moment unpatched organisations and a powerful discovery tool meet in the open.
How do I calculate release-day patch capacity for my organisation?
Multiply your dependency-tree size by an assumed disclosure touch rate (0.5% to 2% is a defensible planning range), discount by the small share of findings likely to have an upstream fix, and divide by 14 days. That gives the daily mitigation rate you'd need. Compare it with your measured throughput from real change records, and close any gap with pre-agreed mitigations such as isolation and kill switches rather than optimism.
Does using mature, widely audited open source protect me from AI-found flaws?
Less than it used to. The claims under examination involve flaws that survived decades in heavily reviewed code, and remediation data points to maintainer capacity, not code age, as the bottleneck. Census II found the most widely used libraries rest on a handful of maintainers, so popularity concentrates release-day exposure rather than diluting it.
Related
- The Sovereignty Premium: Why Sovereign AI Solutions for Enterprise Are Winning on Access, Not Speed
- Washington Put Its Own AI Lab on a Risk List. That Changes What AI Vendor Lock-In Means
- Why Enterprise AI Pilots Fail to Scale: It's Trust, Not Capability
- Security & Trust
Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.