From 29,000 Findings to 516 Fixes: Why Vulnerability Management Must Move to Remediation

As of October 2, 2026, Anthropic’s own coordinated vulnerability disclosure (CVD) dashboard counts 516 vulnerabilities patched upstream out of 29,439 AI-generated candidates, which is 1.75% of everything found and 8.4% of the 6,157 reported to maintainers. Discovery is no longer the bottleneck. Vulnerability remediation is. That gap is what AI vulnerability discovery looks like at scale.

TL;DR

• The hard remediation number exists and it is small: 516 patched upstream, 584 identifiers issued (219 CVEs and 365 GHSAs), 5,103 reports acknowledged, from 29,439 candidates across 591 projects (Anthropic CVD dashboard, October 2, 2026). Anthropic adds that a patch landing upstream “does not guarantee that those patches have been widely installed.”
• Discovery is now cheap and accurate (92.7% true positives among 6,123 firm-reviewed findings), so the constraint has moved to triage, acceptance and remediation; the response is to prioritise on exploitability, exposure, reachability and business context rather than chase 29k items.
• The payoff of OSS Scanner and Glasswing is the wave of upstream patches they are creating; enterprises that cannot map those fixes to owners and ship them as bundles will turn them into another backlog, while median KEV remediation already sits at 43 days (Verizon DBIR 2026).

From 29,000 Findings to 516 Fixes: Why Vulnerability Management Must Move to Remediation

Executive summary: AI has made finding vulnerabilities cheap, so vulnerability management now succeeds or fails on prioritisation, ownership and the speed at which enterprises consume upstream fixes.

Key takeaways:

1. Anthropic’s dashboard shows 516 upstream patches from 29,439 candidates as of October 2, 2026; treat discovery counts as input, not outcome.
2. Score every finding on Risk = Exploitability + Exposure + Reachability + Business Context before it reaches an engineer.
3. Watch the upstream projects you depend on; the OSS Scanner reports go to maintainers, not to you.
4. Decide risk acceptance explicitly, with an owner, an expiry date and a compensating control.
5. Measure time from upstream patch to deployed fix in your estate, because that is the window an attacker now works in.

The Problem

I like what Anthropic shipped on October 8. OSS Scanner gives eligible open source projects free, periodic scans from its strongest models, including Claude Mythos, and each report carries a reproducer, an explanation, a bisection where possible and a candidate patch. The programme is modeled on Google’s OSS-Fuzz and enrollment happens by pull request to a GitHub repo. That is useful defensive work, and the maintainer feedback is strong.

Project Glasswing is Anthropic’s programme that gives a small group of trusted organisations early access to Mythos-class models for defensive security work.

The announcement also contains the most honest sentence I have read from a vendor this year: “We have discovered over 29,000 candidate vulnerabilities, but have only been able to manually review and triage approximately 6,000 of these… we remain bottlenecked on our human capacity to validate these findings.”

So I went looking for the number nobody puts in a headline. How many of the 29,000 actually got fixed?

Anthropic publishes it. The coordinated vulnerability disclosure dashboard, last updated October 2, 2026, reads like a funnel:

The stages overlap rather than run in sequence: the firm review sample (6,123), the triaged reports (1,333) and the severity heatmap sample (1,337) are different subsets on the dashboard.

516 patched out of 29,439 candidates is 1.75%. Measured against the 6,157 reported, it is 8.4%. Measured against the 5,674 confirmed valid, it is about 9.1%. VentureBeat’s comparison of snapshots shows the trend is improving: reported findings grew from 1,596 on May 22 to 6,157 on October 2 (3.9x), while patches grew from 97 to 516 (5.3x).

Anthropic is careful with that 516. It counts fixes “to our knowledge,” and its May update said patches are likely undercounted because “some vulnerabilities are patched without a public advisory.” It also states that “Patched upstream” does “not guarantee that those patches have been widely installed.” Patrick Garrity of VulnCheck found the numbers off in both directions. In June the dashboard “sat at just 27 fixed vulnerabilities” against 88 published advisories. In September it claimed 421 findings patched upstream while “the ledger itself shows only 202 fixed findings.” That tells me to read the dashboard as a directional indicator rather than a final tally.

Even the vendor running the programme cannot keep a clean count of what got fixed. Security teams do not lack data. They lack context and ownership, and Glasswing shows that at ecosystem scale.

Technical Analysis

Discovery got cheap and accurate

On the CyberGym benchmark, Anthropic reports LLMs went from finding under 20% of the benchmark’s vulnerabilities at the start of 2025 to over 85% in 2026. Quality held up. In the OSS Scanner validation run, expert pentesters checked 97 critical and high findings across 48 projects: 85 (88%) met the CVD bar, 11 were real but duplicates, and 1 was a false positive.

Maintainers confirm the signal. Todd Ouska of wolfSSL: “of the 74 reports we received, all but two were valid, and five became CVEs. With patches attached, the reports slotted right into our existing process.” Noah Misch of PostgreSQL said several reports “came with fixes we can use nearly as-is,” and fast-track access let the team fix issues “before they reached a GA release.” Anton Arapov of OpenSSL said a report with a real exploit attached is “basically job done for an engineer as you can verify it right away.” Daniel Stenberg credited the scanner with finding “one of the worst curl vulnerabilities reported in the last few years.” Eddie Kohler of HotCRP praised its grasp of the project’s “complex permission model.”

Severity is where the model and humans disagree

Accuracy on “is this real” is not the same as accuracy on “how bad is this.” Anthropic concedes that maintainers say “severity ratings can be inflated or the scanner misunderstood the project’s threat model.” The dashboard’s severity heatmap quantifies it: across 1,337 firm-triaged findings, Claude and the firms agreed exactly 83.0% of the time. Of the findings Claude called critical, the firms rated 116 critical, 121 high, 7 medium and 15 low. Fewer than half kept their critical rating. Anthropic explains that firms bring project context the model lacks, “which is why their assessments tend to be lower.”

That is the core point for enterprise vulnerability management. A severity label without your threat model is a guess. Anthropic’s own fix is a threat_model.md file that tells the scanner which inputs are adversarial and what is out of scope. Your programme needs the same thing at estate level.

Acceptance is a human throughput problem

Maintainer capacity is the hard ceiling. Anthropic’s May update said several maintainers asked it to slow disclosures, and that a Mythos-found high or critical bug takes two weeks to patch on average. It also noted that Claude Security users patched over 2,100 vulnerabilities in 3 weeks, faster “because enterprises are fixing their own code, whereas open-source fixes usually require volunteer maintainers.”

The slop era made that ceiling worse. In his July 2025 post “Death by a thousand slops,” Stenberg wrote that AI slop made up “about 20 percent of all submissions” to curl and that “the valid-rate has decreased significantly,” and curl ended its bounty at the end of January 2026. By April 2026 he described the reverse problem: “a massive load of good reports.” Google paused its OSS VRP on October 1, 2026, citing “a significant rise in automated submissions, the vast majority of which are not valid.” Good reports or bad, the volume lands on the same few people.

AI-written patches do get merged, with caveats. Watanabe and colleagues’ study of 567 Claude Code pull requests across 157 open source projects (arXiv:2509.14745) found 83.8% merged, against 91.0% for human PRs, but only 54.9% of the merged ones went in without further modification. Alam, Mondal and Roy’s MSR ’26 study of 8,106 fix-related agent PRs from the AIDEV-POP dataset (arXiv:2602.00164) found 65.0% merged, 26.1% closed without merging and 8.9% still open. Candidate patches shorten the path to a fix. They do not remove the reviewer.

Code volume keeps rising on the other side of the ledger

Sundar Pichai wrote on April 22, 2026, during Google Cloud Next, that “75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall.” Satya Nadella put Microsoft at 20 to 30% a year earlier, in April 2025. More code means more surface. NIST says CVE submissions grew 263% between 2020 and 2025, and on April 15, 2026 it stopped trying to enrich everything: backlogged CVEs published before March 1, 2026 moved to “Not Scheduled,” with priority going to KEV entries, federal software and EO 14028 critical software. Sonatype’s 2026 report found 65% of open source CVEs were left without an NVD CVSS score.

Remediation is going the wrong way. The Verizon DBIR 2026 found vulnerability exploitation is now the top initial access vector at 31% of breaches, the median time to fully remediate a KEV vulnerability rose from 32 to 43 days, and only 26% of KEVs were fully remediated.

Exploitation timelines collapsed

Mandiant’s M-Trends 2026 estimates the mean time to exploit in 2025 at minus 7 days on average, exploitation began a week before a patch existed, down from 63 days in 2018. Anthropic’s N-day research shows why patches themselves are now a risk signal: on 21 Windows kernel patches, Mythos Preview produced its first proof of concept in 31 minutes and succeeded on 18 of the 21 within 6 hours, for roughly $2,200 in API credits. On Firefox, the first PoC took about 12 minutes. The OSS Scanner announcement says plainly that “exploits can now be developed in minutes.”

Put the two timelines together. A fix lands upstream, the diff becomes a roadmap, and a 43-day median enterprise rollout leaves weeks of exposure.

Most findings will never matter, and that is the opportunity

The FIRST EPSS research found 6.4% of 192,035 published CVEs were observed exploited; NIST CSWP 41 cites roughly 5%. Endor Labs found 95% of vulnerable dependencies are transitive and, in its 2024 report, that 90.5% of dependency vulnerabilities in the languages studied had no call path to the vulnerable function. Endor Labs also found that 24% of dependency vulnerabilities need a major version upgrade to fix. Sonatype counted more than 42 million downloads of vulnerable Log4j versions in 2025, 13% of all Log4j downloads, and nearly 1.8 billion avoidable vulnerable downloads from just 4 Java components with fixes available.

The fixes exist. Consumption is the failure.

The Phoenix Approach

The LinkedIn discussion that prompted this post made the argument in two lines: the trick is prioritising the vulnerabilities that matter, and the real value is the patches coming out of this wave of open source PRs and fixes. I agree with both, and they are the same problem viewed from two ends.

At Phoenix Security we score with Risk = Exploitability + Exposure + Reachability + Business Context. Exploitability pulls KEV, EPSS and exploit intelligence. Exposure asks whether the asset faces the internet or untrusted input. Reachability asks whether the vulnerable function runs, in code and in containers that actually execute. Business Context asks what the asset supports and who owns it. Only findings that score across those dimensions reach the engineering backlog.

Ownership comes next. Every finding maps to a team through code-to-cloud lineage, repository ownership rules and CMDB data. A finding with no owner is noise, however critical the label.

Then fix bundles. When wolfSSL, PostgreSQL or FreeRDP ships a fix from this wave, it often resolves several CVEs at once. We group findings by remediation unit (upgrade this library, rebase this base image) so one ticket closes 40 findings rather than generating 40 tickets.

This is what we mean by AI-Agent-Second: Context, then Prioritisation, then Agent Assistance. Our Researcher agent gathers exploit and advisory context, the Analyzer agent assesses reachability and blast radius, and the Remediator agent drafts upgrade plans and pull requests. Every output is reviewable and an engineer approves the change. The agents speed up humans; they do not replace the decision.

Risk acceptance belongs in the same workflow. Some findings are real and still not worth fixing now: unreachable code, a threat model that excludes the input, a compensating control already in place. Anthropic’s own true-positive rate counts “won’t fix” findings as real. Real and worth fixing now are separate decisions. Record each acceptance with an owner, an expiry date and the compensating control it relies on, so it comes back for review instead of turning into a silent exception.

Real-World Example

At ClearBank, Phoenix container lineage reduced 467,000 container vulnerabilities to under 8,000 actionable items, a 98% reduction in actionable vulnerabilities, and cut criticals by 96%, from 1,470 to 48. The team did it by removing findings in containers that never run and tracing the rest to the base image or build file that introduced them.

That is the shape of the OSS problem too. 29,439 candidates is not a work queue. The few hundred upstream fixes that touch reachable, exposed, owned assets in your estate are.

Practical Guidance: Monday Morning

1. Pull your SBOMs and list which projects on the anthropics/oss-scanner enrolment list, and on the Anthropic CVD dashboard’s public CVE and GHSA list, appear in your dependencies, including transitive ones.
2. Subscribe to advisories and release feeds for those projects so an upstream fix generates a signal in your pipeline on the day it ships.
3. Apply the risk formula and send only reachable, exposed, exploitable findings to engineering; record everything else as accepted with an expiry date.
4. Map each surviving finding to an owner before you open a ticket; if you cannot name the owner, fix that first.
5. Group fixes into bundles by library upgrade or base image rebase, and test the upgrade path, since Endor Labs data shows major version bumps carry breaking changes.
6. Track time from upstream patch release to production deployment as a first-class metric next to MTTR.
7. Prepare reporting paths. In the US, BOD 22-01 sets KEV remediation deadlines for federal agencies, and many private teams use KEV the same way. In the EU, Cyber Resilience Act Article 14 has applied since September 11, 2026: manufacturers must send an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a notification within 72 hours, and a final report within 14 days of a fix becoming available. In the UK, the Cyber Security and Resilience Bill is in the House of Lords, with Royal Assent expected between late 2026 and spring 2027; the NCSC’s guidance on patching and exposure reduction applies now.

Next Steps

1. Run a backlog audit: count raw findings, duplicates across scanners, unreachable findings and findings without owners.
2. Pilot fix bundles on the 10 open source libraries that carry the most reachable risk in your estate.
3. Talk to us about Phoenix Security ASPM if you want ownership attribution and fix bundles working across code, containers and cloud.

Protect yourself with the latest threat intelligence, get access to PHOENIX BLUE Today