For roughly three decades, coordinated vulnerability disclosure has rested on a specific economic arrangement. Security researchers possessed scarce, hard-won expertise. Discovering a subtle memory corruption bug or a cryptographic implementation flaw required deep domain knowledge, significant time investment, and often a degree of creative intuition that was genuinely difficult to replicate. Maintainers, in exchange for receiving that insight privately before public disclosure, owed researchers responsiveness, attribution, and a reasonable remediation timeline. The whole system was predicated on scarcity of the underlying skill.
That scarcity assumption is now under serious pressure. Filippo Valsorda, formerly lead of the Go Security team at Google and currently a professional open source maintainer through Geomys, has written a pointed and uncomfortable piece arguing that vulnerability reports are not special anymore. The argument is worth taking seriously, not because it is entirely correct in every dimension, but because it identifies a genuine structural shift that the security community has been slow to confront directly.
The Scarcity Argument and Its Collapse
The classical model of coordinated disclosure, sometimes called responsible disclosure though Valsorda rightly notes the moral loading of that term, was built on three pillars. First, the researcher possesses insight the maintainer lacks. Second, the researcher offers confidentiality in exchange for a structured response, protecting users during the remediation window. Third, the maintainer's responsiveness signals genuine care for user security.
Each pillar depended, implicitly, on the first one holding. If the insight is no longer scarce, the entire exchange relationship changes character. Valsorda's claim is that large language models have effectively commoditised the vulnerability discovery phase. Anyone with API access, or increasingly with a locally-run open-weight model, can now perform the kind of static analysis, pattern matching, and heuristic reasoning that previously required a skilled human researcher investing days or weeks of effort.
This is not merely a theoretical observation. The empirical record from 2024 and 2025 is instructive. Multiple research groups demonstrated that GPT-4-class models could identify real CVEs in C codebases with non-trivial precision when given appropriate prompting scaffolding. Google's Project Zero and academic groups at institutions including ETH Zurich have published results showing LLM-assisted fuzzing and static analysis pipelines discovering previously unknown vulnerabilities in production software. The capability gap between a well-resourced attacker running automated LLM analysis and a skilled independent researcher has narrowed considerably.
The Triage Bottleneck Has Shifted
What this creates is a situation where the bottleneck in the vulnerability pipeline has moved. Previously, discovery was hard and triage was relatively straightforward: a researcher presented a well-characterised issue, the maintainer verified it, and the path to remediation was clear. Now, both defenders and attackers can generate large volumes of candidate vulnerabilities cheaply. The hard problem is no longer finding potential issues; it is determining which candidates represent genuine, exploitable flaws in realistic deployment conditions.
This matters for how maintainers should allocate their time. If a security@ inbox is receiving reports where a significant fraction were generated or substantially assisted by LLMs, and if the maintainer can run equivalent or better analysis themselves with full codebase context, then the traditional obligation to treat each report as a high-priority, time-sensitive item starts to look less defensible. The signal-to-noise ratio of an LLM-assisted vulnerability report from an unknown external researcher may genuinely be comparable to, or worse than, the output of a well-tuned internal CI pipeline.
Valsorda makes a related point about embargoes and confidentiality. The classical argument for the embargo period was that attackers needed time to read and understand a disclosure post before they could exploit the vulnerability. If attackers can now independently rediscover vulnerabilities using the same LLM tooling available to researchers, the practical value of a 90-day embargo window is reduced. The window still matters for patch deployment, but the assumption that the vulnerability is truly secret during that window is increasingly questionable.
What the Research Literature Says About LLM Security Capabilities
It is worth being precise about what LLMs can and cannot currently do in this space, because the argument's validity depends on the actual capability level rather than hype.
- Pattern-based vulnerability detection: LLMs perform well at identifying known vulnerability classes in code that resembles their training distribution. SQL injection, buffer overflows following common patterns, and insecure cryptographic usage are reliably flagged.
- Novel vulnerability classes: Performance degrades significantly for genuinely novel vulnerability patterns, complex multi-component interactions, or vulnerabilities requiring deep understanding of runtime semantics rather than syntactic patterns.
- False positive rates: Current models produce substantial false positive rates in security analysis tasks, which is precisely what creates the triage bottleneck Valsorda describes. A 2024 study from Carnegie Mellon found false positive rates exceeding 60% for LLM-based static analysis on real-world C++ codebases.
- Context window limitations: Large, complex codebases with subtle cross-module vulnerabilities remain difficult for models with even 128k-token context windows, though retrieval-augmented approaches are beginning to address this.
Valsorda acknowledges the capability is not yet uniform, noting that open-weight models lag closed frontier models by roughly one to three months. That gap is real but shrinking. The more important point is directional: the trend is toward commoditisation, and security policies designed for 2015 conditions are already misaligned with 2026 reality.
Implications for Open Source Maintainers and Security Policy
If we accept the core argument, several practical implications follow for how open source projects should structure their security practices.
The traditional security@ email address as a primary intake mechanism deserves reconsideration. It creates an obligation channel that may consume significant maintainer time for reports with low signal quality. Valsorda references curl's temporary suspension of vulnerability reporting channels as an extreme response that he initially disagreed with, but acknowledges he cannot now construct a strong argument against. A more calibrated approach might involve tiered intake: reports from researchers with established track records or prior trust relationships receive the traditional coordinated response, while unvetted reports from unknown parties are processed through a lower-priority queue with explicit expectation-setting about response timelines.
The case for integrating LLM-based static analysis directly into CI pipelines is strengthened considerably by this analysis. If the maintainer can run continuous automated vulnerability scanning with full codebase context, the marginal value of an external report decreases further. Projects like OSS-Fuzz already demonstrate the value of automated continuous fuzzing; extending this with LLM-assisted semantic analysis is a natural evolution. The engineering cost of setting this up is now low enough that it should be considered baseline practice for any project with significant security surface area.
Attribution norms also warrant re-examination. The convention of crediting vulnerability reporters in CVE records and release notes made sense when discovery represented substantial human effort. When a report is primarily the output of a five-minute LLM query, the appropriate level of credit is less obvious. This is not an argument for eliminating attribution, but for decoupling it from the automatic, high-status treatment that coordinated disclosure has historically conferred.
What Remains Genuinely Valuable in External Security Research
The argument should not be read as dismissing external security research entirely. Several things that skilled human researchers contribute remain difficult to automate.
Deep architectural analysis, where a researcher understands the threat model of a system well enough to identify design-level weaknesses rather than implementation bugs, is not well-served by current LLMs. Protocol-level vulnerabilities in cryptographic systems, timing side-channels requiring careful empirical measurement, and vulnerabilities that only manifest under specific deployment configurations all require human judgment and expertise that the current generation of models handles poorly.
There is also the question of accountability and trust. A named researcher with a public reputation has skin in the game when making a vulnerability claim. An LLM-generated report has no such accountability structure. For high-stakes projects, the social and epistemic value of a credible human researcher remains real, even if the raw technical insight they provide is increasingly replicable.
The broader shift Valsorda is pointing at is real and the security community should engage with it seriously rather than defaulting to institutional inertia. Policies, norms, and tooling built for a world of scarce security expertise need updating for a world where that expertise is being rapidly automated. The maintainers who adapt their workflows to this new reality, running continuous automated analysis, maintaining tiered intake processes, and focusing human attention on the triage and remediation work that genuinely requires it, will be better positioned to protect their users than those who continue treating every security@ email as a sacred obligation regardless of its provenance or quality.
The job has not gotten easier. It has gotten different.