AI Patch Gap: 25 CVEs a Day, 1.5 Fixes — Swiss Guide 2026

Over roughly nine weeks, Anthropic's Claude Mythos Preview combed through more than 23,000 open-source code paths and reported 1,596 verified vulnerabilities across hundreds of projects, with a 90.8% true-positive rate confirmed by external security firms. For scale: OSS-Fuzz, Google's continuous fuzzing programme, recorded around 13,000 vulnerabilities over nine years. An AI system approached that volume in months. But the number that should reorganise Swiss vulnerability-management thinking is not the discovery figure — it is the ratio Tuskira's researchers extracted from the aftermath. Discoveries are arriving at roughly 25 per day while upstream fixes land at about 1.5 per day: a vulnerability deficit of 16.5 to 1. Discovery has been industrialised; remediation has not. Everything between the two — maintainers, advisory databases, dependency scanners — is now operating beyond design capacity.

The Pipeline Was Built for a Slower World

The open-source disclosure pipeline assumes a rhythm: a researcher reports privately, a maintainer acknowledges, a patch is developed, an advisory is published, scanners ingest the advisory, enterprises remediate. Every stage of that chain is saturating simultaneously. At the snapshot Tuskira analysed, maintainers acknowledged reports quickly — median 4.8 hours — but only 6% of the reported vulnerabilities had an upstream patch available, and 95% had no public advisory at all. GitHub's advisory database, the feed on which most commercial dependency scanners ultimately rely, has a review backlog now measured in weeks because reports arrive faster than humans can triage them. The full cycle from disclosure to a fix deployed in production stretches to three to five months.

The volunteer economics underneath make this structural, not transitory. A maintainer of a widely used library is now on the receiving end of AI-generated (if verified) vulnerability reports at a cadence no evening-and-weekend workflow can absorb — and the ImageMagick example in Tuskira's data shows why the workload compounds: a single upstream flaw propagated to more than 18 downstream variants, each needing its own assessment. Discovery scales with compute; patching scales with unpaid human attention. That asymmetry does not resolve on its own.

Your Scanner Is Reporting on the Past

For enterprises the operational consequence is a widening blind spot with a precise shape: the window between a vulnerability's discovery and its appearance in the advisory feeds that scanners consume. Inside that window — now months wide for most of the 1,596 findings — a dependency scan reports "no known vulnerabilities" about components whose flaws are already documented in an upstream issue tracker, a research disclosure, or an attacker's private collection. The scan is not wrong about the database; the database is wrong about the world.

Attackers do not wait for advisories. The Oracle EBS exploitation this month began before public proof-of-concept code existed, and the JadePuffer incident showed an LLM agent chaining reconnaissance to exploitation autonomously — the same class of tooling that finds vulnerabilities at 25 a day is equally available for finding them without reporting them. When discovery tooling is symmetric and disclosure pipelines are not, the advantage sits with whoever acts on raw discovery rather than curated feeds. Tuskira's formulation is the correct planning assumption: enterprises need to operate at discovery cadence, not only remediation cadence.

What This Means Under CRA, ISA, and FINMA Expectations

Swiss organisations carry specific obligations that this gap strains. Manufacturers selling digital products into the EU face the Cyber Resilience Act's vulnerability-handling obligations — including the Article 14 reporting duties taking effect in September — which presume the manufacturer knows about actively exploited vulnerabilities in its products; a scanner blind spot measured in months is difficult to reconcile with a 24-hour reporting clock. Critical-infrastructure operators under the ISA, and financial institutions under FINMA's vulnerability-management expectations, are similarly assessed on how quickly they identify and treat known weaknesses. "Known" is doing new work in that sentence: known to whom, and via which feed? An SBOM-driven programme that tracks upstream repositories, issue trackers, and research disclosures directly — rather than waiting for advisory publication — is becoming the difference between a defensible process and a documented lag.

There is also a quieter procurement implication. If the open-source components inside commercial products carry a 16.5:1 unresolved-vulnerability deficit, then vendor SBOMs, patch-latency commitments, and upstream-contribution practices become due-diligence questions, not nice-to-haves. A supplier that consumes open source at industrial scale while contributing nothing to its maintenance is externalising exactly the risk this data quantifies.

• Maintain a real SBOM, not a point-in-time export. A continuously updated software bill of materials per application is the prerequisite for every other control here — and for CRA conformity and credible ISA reporting.
• Monitor upstream, not just advisories. For your most critical dependencies, track the project's repository, issue tracker, and security mailing list directly; treat a fix commit without an advisory as actionable intelligence.
• Layer discovery-cadence feeds over your scanner. Complement CVE/GHSA-based scanning with sources that surface pre-advisory findings, and measure your scanner vendor on ingestion latency, not just coverage.
• Prioritise by exposure, not only by CVSS. With a months-wide advisory lag, reachability analysis (is the vulnerable path actually invoked?) and internet exposure decide what matters among findings that arrive faster than you can patch.
• Pre-plan compensating controls for the unpatchable window. WAF rules, feature flags, egress restriction, and segmentation buy time when the upstream fix is one of the 94% not yet written.
• Fund the maintainers you depend on. Sponsorship or contributed engineering time on your critical dependencies is now risk reduction with a measurable return — the 1.5 patches a day is a resourcing number, not a talent number.
• Put SBOM and patch-latency clauses in procurement. Require vendors to disclose open-source composition and commit to remediation timelines for components in their products; the deficit ratio is their problem too.

The trajectory is one-directional: discovery tooling gets cheaper and faster every quarter, and nothing in the volunteer-maintained middle of the pipeline scales with it. Advisory databases will add automation, foundations will fund triage, and AI will eventually assist patching as effectively as it assists discovery — but none of that arrives before the gap widens further. Swiss organisations that rebuild their vulnerability management around upstream visibility, reachability-based prioritisation, and compensating controls will treat the deficit as weather: unpleasant, measurable, survivable. Those that keep equating "scanner is green" with "we are fine" have adopted a definition of fine that is now three to five months old.