AI Vulnerability Discovery at Scale: Why Patching Is Hard for Open Source Maintainers and How to Cope

1. A Contradiction Magnified by Numbers

In the past, vulnerability discovery depended on manual audits and limited tooling. The rate at which vulnerabilities were found was roughly matched to the capacity of maintainers to handle them. AI models, especially large language models and related tools, break that balance: a model can scan large codebases, generate many test inputs, and produce thousands of candidate vulnerability leads within hours.

The core problem is that discovery can scale with available compute, while repair is constrained by human judgment, testing, compatibility validation, and coordination. This creates a counterintuitive outcome: the more vulnerabilities are discovered, the more exhausted maintainers become, because the number of pending reports grows faster than the number of vulnerabilities that can actually be fixed.

A representative public case illustrates this gap. One AI security project reported that its model generated more than 29,000 candidate vulnerabilities within six months. After manual review, about 6,000 were confirmed; about 5,000 entered the disclosure process; the leads involved hundreds of open source projects; and only about 600 had known upstream fixes completed, roughly 12% of the disclosed items. This ratio should not be interpreted as a final fix rate. Some vulnerabilities were still in coordinated disclosure, and some fixed issues may not have been counted.

Similarly, widely circulated claims about “nearly 38,000 vulnerabilities” often mix statistical categories: model-generated candidate leads are treated as confirmed real vulnerabilities. The real concern is not the number itself, but the processing gap among discovery, verification, and repair.

2. Why “If AI Can Find It, Why Not Fix It?” Is Misleading

Many people intuitively assume that if AI can locate a defect, it should also provide a fix. However, finding an error and safely fixing an error are fundamentally different tasks.

Consider a typical out-of-bounds memory read. A model may analyze logic, construct special inputs, and identify within minutes that a function accesses invalid memory under boundary conditions. The discovery action is local and reproducible.

When maintainers actually fix the issue, however, they must answer a series of questions:

• Can the defect be triggered in real deployment environments, not only in a minimal reproduction setup?
• Is there a remote exploitation path, and what is the true severity level?
• Will the fix change existing interface behavior or break caller contracts?
• Does the behavior remain consistent across Windows, Linux, macOS, and different architectures?
• Should patches be maintained for multiple historical version branches?
• Will downstream projects experience compatibility regressions after upgrading?

These questions cannot be answered by a single automated scan. Fixing a vulnerability is a decision that requires global context, engineering tradeoffs, and a long-term maintenance commitment, not a simple code replacement. Discovery is an analysis problem; repair is a governance problem.

3. Easing the Pressure: Redesign the Whole Pipeline Instead of Limiting Discovery

Suppressing vulnerability discovery is neither feasible nor necessary. Vulnerabilities exist objectively, and delaying discovery only pushes risk into the future. The practical path is to redesign the entire pipeline from report, verification, and repair to disclosure, so that human effort is concentrated on decisions that only humans can make.

3.1 Move Verification Earlier and Filter Noise with Confidence

A major burden for maintainers comes from false positives. Before reports are submitted upstream, an independent verification stage should be established: every report should include an automatically runnable reproduction script, clear trigger conditions, and a minimal sample. Leads that fail automated reproduction should not directly consume maintainer time.

Candidate leads → automated reproduction verification → deduplication and clustering → impact assessment → disclosure process
              ↓
If verification fails, feedback is sent back and the lead is excluded from the repair queue

3.2 Triage by Severity, Not by Quantity

Not every vulnerability deserves immediate attention. By combining common vulnerability severity scoring concepts with exploitability conditions, vulnerabilities can be divided into three categories: urgent fix, planned fix, and acceptable risk. Low-severity issues with strict trigger conditions can be archived in batches, preventing them from competing for attention with high-risk items.

3.3 Automate Fix Suggestions, but Keep the Final Decision with Humans

AI can provide patch drafts, lists of affected call sites, and regression test cases. However, the authority and responsibility to merge changes remain with maintainers. Tool output should be treated as a proposal rather than a conclusion. This approach can accelerate work without crossing safety boundaries.

3.4 Coordinate Disclosure and Batch Processing

Ad hoc, one-off disclosures repeatedly interrupt maintenance work. A coordinated disclosure window can be established: multiple leads for the same project can be aggregated, a unified response and repair cycle can be defined, and processing and release can be centralized. This also gives maintainers sufficient time for testing.

3.5 Move from Manual Case-by-Case Work to Scalable Collaboration

When an organization faces a massive number of leads, the right approach is not to force individual maintainers to handle everything alone. Instead, it is necessary to build collaboration mechanisms for distribution, claiming, and tracking, allowing contributors, automated systems, and maintainers to each perform their roles. In cloud environments, such workflows can be supported by general-purpose capabilities: use a message queue to buffer report surges, use object storage to archive reproduction materials, use monitoring and alerting to track repair progress, and use a logging service to audit the entire disclosure chain. This can improve throughput without increasing staffing.

4. Conclusion

AI has reduced the cost of vulnerability discovery to nearly zero, but it has not, and likely cannot easily, reduce the cost of repair in the same way. Rather than blaming maintainers for slow fixes, it is more accurate to recognize that repair is a governance task requiring judgment and responsibility.

The way to ease the pressure is not to discover less, but to discover more intelligently, verify more thoroughly, fix more selectively, and disclose more orderly. When repetitive work in the pipeline is absorbed by automation and human energy is directed toward truly critical decisions, open source ecosystems can benefit from the security advantages of AI without being overwhelmed by massive report volumes.