AI Finds Vulnerabilities Faster Than Teams Can Fix Them

The AI Vulnerability Remediation Gap

AI has shifted software security’s bottleneck from finding flaws to validating, prioritizing, and safely deploying fixes. The AI vulnerability remediation gap is the distance between machine-generated findings in open-source and AI dependencies and the human capacity to confirm, assign, patch, test, and release them.

A discovery count is not an urgent-risk count. Findings can be duplicates, unvalidated, unreachable in the deployed product, or missing the execution context needed to judge exploitability. Treating every alert as an emergency would bury findings that affect real systems.

Security leaders should measure throughput at each stage: findings received, validated, prioritized, patched, and deployed. They should rank the queue by reachability, exposure, and exploitability, then apply business impact and dependency spread. AI increases the intake rate; it does not remove the engineering work required to make a fix safe.

How Much Faster Is AI Finding Vulnerabilities?

AI vulnerability discovery is already outpacing the workflow that turns findings into deployed patches. Project Glasswing reported more than 10,000 high- or critical-severity findings in its first month. By May 22, 2026, Anthropic had disclosed 1,596 findings across 281 open-source projects, but maintainers had confirmed patches for only 97. That is roughly 6% of disclosed findings and less than 1% of the initial discovery volume.

Tuskira’s 63-day snapshot shows the rate mismatch directly: roughly 25.3 disclosures per day versus 1.5 findings marked patched per day. The visible gap was approximately 16.5 to 1. Maintainers acknowledged 90.9% of disclosures, so the data does not show that projects ignored the reports. It shows that acknowledgment and remediation require different capacities. A maintainer can validate a report, communicate with the finder, and still lack the time to design, test, release, and propagate a safe fix.

These figures do not mean every disclosed finding is an urgent production risk. They establish that disclosure volume can exceed the capacity of existing advisory and patch workflows. Security teams should therefore measure the rate at which findings become validated, prioritized, patched, and deployed, rather than treating discovery counts as completed security work.

Why Open-Source Remediation Falls Behind Discovery

Open-source remediation is constrained by maintainer capacity and coordination, so faster discovery does not produce faster fixes by itself. An autonomous analyzer can inspect code continuously; a maintainer still has to reproduce the report, determine whether the path is reachable, design and test a fix, publish an advisory, release a new version, and wait for downstream projects to adopt it.

That pipeline has several handoffs: private disclosure, maintainer validation, advisory publication, dependency propagation, regression testing, release, and downstream deployment. A delay at any handoff leaves users exposed. Missing records add another delay. In a study of 6,427 AI/ML open-source bug-bounty reports, 44.4% of CVE IDs assigned to AI/ML vulnerabilities were absent from the National Vulnerability Database. Tools that depend on NVD records cannot alert every affected project when a record is missing.

The same dataset found that 49.5% of AI/ML vulnerabilities with an assigned severity remained unfixed after disclosure. Most non-AI/ML vulnerabilities in the dataset were fixed, at 99.7%. The gap points to patch development and maintenance capacity, not a lack of disclosure intent.

Coordination also multiplies the workload. One upstream issue can create separate downstream tickets across package variants, distributions, and products. Tuskira’s example is an ImageMagick vulnerability that propagated to more than 18 NuGet variants through Magick.NET. One fix therefore requires ecosystem-wide inventory, testing, release, and adoption work, while discovery can remain a single automated operation.

Why Discovery Counts Do Not Equal Urgent Risk

AI findings belong in an intake queue, not an emergency queue. A discovery can be a false positive, duplicate an existing report, lack execution context, or describe code that no deployed request can reach.

Evaluation results explain why. On the Real-Vul dataset, models tested against entire codebases lost up to 95 percentage points of precision and 91 points of F1 compared with isolated-function evaluations. Project context changes the question: a detector must follow data across calls, identify the correct program point, and distinguish reachable behavior from suspicious syntax.

A project-scale study reviewed 6,442 warnings across 24 open-source projects. It found high false discovery rates in both LLM-based and traditional tools. Truncated interprocedural context and incorrect program-point classification were leading causes. The same study found that scans could consume hundreds of thousands to hundreds of millions of tokens, cost more than $1,000, and run for hours or days. That makes indiscriminate validation an operational problem too.

Context-rich evaluation gives a more useful counterpoint. CORRECT evaluated 2,000 vulnerable and patched program pairs across 99 CWEs. Leading models reached 67% accuracy, exceeded 70% F1 on key CWEs, and approached 0.8 precision. Those results support using AI for investigation when the model receives repository and execution context.

The remediation bottleneck therefore weakens at the front of the pipeline. Unvalidated, context-poor findings can increase triage work without representing equivalent risk. Teams should first reproduce the issue, confirm a reachable path in deployed code, and check exposure and exploitability before treating a discovery as urgent.

Can AI Safely Triage or Patch What It Finds?

AI agents can reduce triage effort and draft fixes, but they cannot own the decision to ship them. Their advantage comes from iterative reasoning: an agent can inspect repository history, trace data flow, call static-analysis tools, reproduce an exploit, and run tests against the actual project rather than judge an isolated code fragment.

The gains are measurable. In a SAST filtering study, agents reduced an OWASP Benchmark false-positive rate from more than 92% to 6.3% in the best configuration. On real-world Java CodeQL alerts, the strongest configuration identified up to 93.3% of false positives. On post-cutoff OSS-Fuzz data, SWE-agent with Claude Sonnet 4 identified 95.5% of false positives while maintaining 95.5% precision. Those results are useful, but they are not universal. Performance varied by model backbone and CWE, and aggressive filtering can suppress true vulnerabilities. Agent runs also carry material token and compute costs.

Patch generation has the same boundary. SANS, citing 1Password research, reports that AI-generated patches fail to remove the underlying flaw or introduce a new defect more than half the time. Every candidate fix therefore needs exploit reproduction, regression and security tests, differential review, and staged deployment. This position should change only after independent evaluations show high recall and low regression rates across repositories and CWE classes, not only benchmark alerts.

What Should Teams Prioritize Before Advisories Arrive?

Prioritize findings by reachability, exposure, and exploitability, not by AI discovery counts or CVSS alone. Advisory latency is a risk factor: Tuskira estimates 90 to 150 days from private disclosure to a patch in production, while CVE submissions rose 263% from 2020 to 2025 and strained NVD processing.

Exploitability should break close calls. A reported 28.3% of CVEs are exploited within 24 hours of disclosure, and median disclosure-to-weaponized-exploit time fell from 771 days in 2018 to single-digit hours. Waiting for an NVD record is therefore unsafe for reachable, exposed assets.

Run parallel workstreams: validate the finding, contain exposure, coordinate the upstream maintainer, test the patch, and update dependency ownership and inventory. This avoids making advisory publication the gate for action. A high CVSS score without a reachable deployment is a queue item. A lower-scored flaw with a working exploit against an internet-facing service is the incident.

Where Does the Bottleneck Thesis Stop Holding?

The remediation bottleneck is not universal. When findings are noisy, context-poor, or disconnected from deployed assets, validation becomes the scarce resource.

Project-scale evaluations show why. LLM detectors can produce hundreds of thousands to hundreds of millions of tokens, cost more than $1,000, and run for hours or days. Teams with incomplete asset inventories or unclear ownership then spend more time proving reachability than fixing code. Without reproducible evidence, a large AI-generated queue measures investigation effort, not urgent risk.

That qualification does not overturn the thesis for validated findings. Once a vulnerability is confirmed in reachable, deployed code, repair capacity remains constrained. The 2025 State of Pentesting report found that only 21% of serious LLM pentest findings were resolved. Across all pentest findings, median resolution time was 67 days against a commonly favored 14-day SLA. Those figures show an operational repair gap even after human validation.

The thesis therefore applies most strongly after a finding is tied to a real asset and attack path. Better context or lower exposure would weaken it; a validated high-impact queue with the same remediation throughput would strengthen it.

How Security Leaders Should Operate the Remediation Gap

Treat remediation and triage capacity as the constraint. Use AI inside a governed process, not as an autonomous patch pipeline.

Track each finding through six states: received, validated, prioritized, patched, deployed, and reopened. Set service levels by reachability and exposure. Keep dependency and ownership graphs complete, and ingest private disclosures without waiting for NVD updates.

Require reproducible proof-of-concept validation and an exploitability check. Agents can gather repository context, trace data flow, and draft candidate fixes. Humans must review those fixes, run regression and security tests, and approve staged production rollout. Record downstream propagation so one upstream patch reaches every affected product.

Prioritize findings that are validated, reachable, externally exposed, exploitable, and consequential. Label uncertain, duplicate, or unreachable findings for investigation instead of treating each AI discovery as an emergency. The AI vulnerability remediation gap is therefore an operating-capacity problem: discovery scales with compute, while safe triage and deployment still require accountable ownership.