Vulnerability Reports Are Not Special Anymore

Last updated: June 24, 2026

Filippo Valsorda, the cryptography engineer behind the Go cryptography standard library and age encryption, published an essay this week arguing that vulnerability reports no longer deserve special treatment. The reason: LLMs can now find vulnerabilities "as good as almost any security researcher."

The post sparked a 170+ comment discussion on Hacker News, with maintainers, security researchers, and vendors all weighing in on whether the old coordinated disclosure model still makes sense in 2026.

The Core Argument#

Valsorda's thesis is straightforward. Vulnerability reports historically received privileged treatment because security researchers provided two scarce resources:

1. Valuable insight into potential vulnerabilities
2. Confidentiality allowing fixes before public disclosure

In exchange, maintainers offered responsiveness and public credit.

Both sides of this bargain have eroded. LLMs can now perform vulnerability discovery at scale. The insight isn't scarce anymore. And confidentiality matters less when any attacker can run the same LLM analysis independently and find the same bugs.

"The insight is not scarce and precious anymore," Valsorda writes. If an AI found the vulnerability, there's no reason to assume attackers haven't already found it too.

The practical conclusion: maintainers should prioritize rapid triage and remediation over courteous researcher communication. Implement LLM-based scanning in your CI/CD pipeline. Reserve special treatment only for unusually severe cases or highly-trusted sources.

What HN is Saying#

The thread surfaces both validation of the problem and pushback on the solution.

Maintainers confirm the spam problem is real. One maintainer of a vulnerability disclosure program reports that submissions went from 5 per month to 5 per day since January 2026. "These are clearly AI-generated and extremely low quality (albeit well-written). The rules of the program aren't read." They're considering shutting down the program entirely.

Dependabot fatigue compounds the issue. Several developers describe getting 100+ vulnerability alerts per week, mostly for dev dependencies or issues that don't affect their actual attack surface. "Half of them for dev dependencies," one writes. The signal-to-noise ratio has collapsed.

ReDoS is the poster child for broken scoring. Multiple commenters point to regex denial-of-service vulnerabilities that get marked as 10/10 severity despite being in build-time code that never sees untrusted input. "We got 116 github dependabot alerts this week. Half of them for dev dependencies."

The payment friction idea emerges. One commenter suggests requiring a small payment to submit vulnerability reports, refunded on valid findings. This triggers immediate pushback: "Why would anyone pay money to have a chance of being arrested?" The legal risks of security research already create friction - adding financial friction could discourage legitimate researchers entirely.

Supply chain concerns complicate the dev-dependency dismissal. Several commenters note that dev dependencies are still attack vectors - SolarWinds was compromised through its build tooling. "Developer's machines and cicd systems are high value targets." Dismissing dev dependency alerts entirely isn't risk-free.

Some question the AI capability claim. Not everyone agrees that LLMs can find vulnerabilities as well as skilled researchers. The counterargument: AI-generated reports are mostly garbage, suggesting the discovery capability isn't actually that strong. Valsorda's framing may overstate where we are today while being correct about the trajectory.

Read the full discussion at Hacker News.

What This Means for Developers#

If you maintain open source software or run a vulnerability disclosure program, this shift creates practical problems:

Triage becomes the bottleneck. When anyone can generate plausible-looking vulnerability reports, filtering real issues from AI-generated noise becomes the core challenge. Quality scoring, source reputation, and automated validation become more important than manual review of every submission.

The AI-found vulnerability paradox. If AI can find a bug, assume adversaries have already found it. This changes disclosure timelines - you may want to patch faster and skip the courtesy dance.

Bug bounty economics shift. Programs that pay per valid bug create incentives for volume submissions. Expect more platforms to adopt filtering mechanisms like video reproduction requirements, reputation gating, or even the controversial payment friction model.

Run your own scans. If LLMs can find your vulnerabilities, you should be running those scans yourself before researchers (or attackers) do. Integrate security scanning into CI/CD rather than relying on external reports.

Dev dependency alerts still matter, sometimes. Don't dismiss all dev dependency vulnerabilities, but do context-aware triage. A ReDoS in your test framework is different from malicious code in a build tool.

The Broader Shift#

Valsorda's essay is part of a larger pattern: AI commoditizing expertise-based workflows. Security research joins code review, penetration testing, and other traditionally specialized domains where AI tools are compressing the skill curve.

This doesn't mean security researchers are obsolete. The hardest vulnerabilities - novel attack classes, complex chains, hardware-level exploits - still require human expertise. But the long tail of straightforward vulnerability discovery is increasingly automatable.

For maintainers, this means the volume of incoming reports will keep growing while the average quality drops. The workflows designed for a world of scarce, thoughtful security researchers need to adapt to a world of abundant, mechanical scanning.

The old model assumed vulnerability reporters were partners deserving special treatment. The new model may need to assume they're noise until proven otherwise - and design systems accordingly.

FAQ#

Why does Filippo Valsorda say vulnerability reports are not special anymore?#

Vulnerability reports used to get privileged treatment because researchers supplied scarce insight and confidentiality. Valsorda argues LLMs can now find vulnerabilities about as well as almost any security researcher, so the insight is no longer scarce, and confidentiality matters less when an attacker can run the same analysis and find the same bugs.

What should open source maintainers do about AI-generated vulnerability reports?#

Valsorda's conclusion is to prioritize rapid triage and remediation over courteous researcher communication, run LLM-based scanning in your own CI/CD pipeline, and reserve special treatment for unusually severe cases or highly trusted sources.

Are AI-generated vulnerability reports overwhelming disclosure programs?#

Some are. One maintainer of a vulnerability disclosure program reported submissions rising from 5 per month to 5 per day since January 2026, mostly AI-generated and low quality, and said they were considering shutting the program down.

Should developers ignore dev dependency vulnerability alerts?#

Not entirely. Commenters noted dev dependencies are still attack vectors, since developer machines and CI/CD systems are high-value targets. The post recommends context-aware triage: a ReDoS in your test framework is different from malicious code in a build tool.

Continue Reading#

• Distilling an LLM on One GPU: Offline Top-K Logits and a Fused Chunked KL Loss
• Fable 5 Effort Levels vs Switching Models: When to Dial and When to Change
• The Fable 5 Orchestrator Playbook: One Smart Model Managing Cheap Workers

Sources#

• Vulnerability reports are not special anymore - Filippo Valsorda
• HN Discussion (170+ comments)
• Scanii Vulnerability Disclosure Program Rules (example of video reproduction requirement)