Valsorda argues that the coordinated-disclosure regime was a fair trade only when researchers spent weeks finding real bugs in exchange for embargo time. Now that LLM hallucinations, Semgrep-spam, and CVE-resume-padders dominate the inbox, maintainers are forced into elaborate rituals for ten-minute reports — so vulnerability reports should be treated like any other GitHub issue: judged on merit and closed if wrong.
Valsorda's secondary argument is that CVEs are no longer a reliable indicator of meaningful vulnerability because the assignment process rewards volume and resume-padding rather than substantive findings. Downstream consumers — scanners, compliance tooling, dependency auditors — keep treating each CVE as authoritative, which forces maintainers to engage with garbage reports just to prevent bad CVEs from being filed against them.
The 138-comment HN thread is notable for the absence of pushback — other open-source maintainers are largely nodding grimly rather than defending the existing disclosure regime. The shared experience of receiving low-effort, AI-assisted vuln reports has produced a rare consensus that the old norms no longer match reality.
Filippo Valsorda — formerly Go's cryptography lead at Google, now a full-time independent open-source maintainer funded by retainers — published *Vulnerability reports are not special anymore* on his blog. The post hit 254 on Hacker News, which for a Filippo post is about par; what's notable is that the comment thread is mostly other maintainers nodding grimly rather than arguing.
The thesis is blunt. For two decades, the security community trained maintainers to treat vulnerability reports as a sacred class of bug: private channel, embargoed timeline, coordinated disclosure, CVE assignment, the works. That regime assumed the reporter had done real work — reverse-engineered a binary, fuzzed a parser, found a logic flaw nobody else had — and was offering it to you in good faith in exchange for credit and a few weeks of quiet to patch.
That assumption is dead. Valsorda's argument is that the modal vulnerability report in 2026 is one of three things: an LLM hallucinating a CVE from a stack trace it doesn't understand, a bug-bounty farmer running Semgrep against your repo and copy-pasting the output, or a CVE-resume-padder filing against a dependency you transitively pull in. None of these warrant the elaborate ritual. They warrant the same treatment as any other GitHub issue: read it, judge it, close it if it's wrong, fix it if it's right.
The coordinated-disclosure regime was always a compromise between two groups that didn't trust each other: researchers who wanted credit and maintainers who wanted time. It worked when both sides paid roughly equal costs — the researcher spent weeks finding the bug, the maintainer spent weeks fixing it, and the embargo was a fair trade. The arrival of cheap LLM-assisted scanning and the professionalization of CVE-farming has obliterated that symmetry. The reporter now spends ten minutes; the maintainer still spends weeks if they play along.
Worse, the CVE itself has become a load-bearing piece of compliance theater. Once a CVE is assigned, it propagates into every SBOM scanner, every FedRAMP audit, every enterprise procurement checklist. A maintainer who pushes back on a bogus CVE is fighting not just the reporter but Dependabot, Snyk, GitHub Advisory Database, and a customer's compliance team who all treat the CVE ID as ground truth. The cost of a wrong CVE is borne entirely by the project; the benefit accrues to whoever filed it. Valsorda has been on the receiving end of this for the Go cryptography stack, age, mkcert, and his retainer projects — he has more standing than almost anyone to call it.
The community reaction in the HN thread is the interesting tell. Daniel Stenberg (curl) has been making the same argument for two years and posts curl's hardline policy as a template: report it, we'll triage it, we'll publish a CVE when *we* think it warrants one, and if you don't like that timeline you can publish whatever you want. Greg KH has banned entire categories of LLM-generated reports from kernel.org. The Linux kernel CNA now issues its own CVEs in part to prevent third parties from issuing nonsense ones on its behalf. What was a fringe position in 2023 — Stenberg got hate mail for it — is now consensus among maintainers of any project large enough to be a target.
There's a second-order effect Valsorda hints at but doesn't fully name: this asymmetry is one of the load-bearing reasons OSS maintenance is collapsing. The maintainer cost of *fielding* security reports has become a meaningful fraction of total maintenance work, and unlike feature development or bug triage, it can't be deferred or batched. An embargo creates a deadline you didn't agree to, set by someone you didn't choose, around a bug that may not exist. Multiply by the long tail of dependencies and you get the curl situation: Stenberg processing dozens of LLM reports a week, all of which require thoughtful response because dismissing the rare real one is catastrophic.
If you maintain anything with more than a few hundred stars, the operational shift is straightforward and overdue. Publish a SECURITY.md that explicitly says you do not honor embargoes by default, do not assign CVEs on demand, and will treat reports on their technical merits — not because the reporter invoked the magic word 'vulnerability.' Steal curl's policy verbatim if you want; Stenberg has explicitly invited this. Route security@ to the same inbox as your bug tracker. Stop running a separate disclosure pipeline that exists mostly to make reporters feel important.
If you're a downstream consumer — and most of us are, far more than we're maintainers — the implication is uglier. The CVE database is now a noisy signal, and treating it as a clean one means you're going to spend engineering cycles on phantom risk. Scanners will keep flagging Go stdlib CVEs that don't affect your usage, Node packages with theoretical prototype-pollution vectors no exploit has ever materialized for, and transitive dependencies three layers deep where the 'vulnerable' function isn't reachable from your code. The right response is investment in reachability analysis (Semgrep Pro, Endor Labs, Socket, or the open-source `govulncheck` which Valsorda himself helped design and which only reports vulnerabilities in code paths your binary actually calls) rather than performative remediation of every yellow row in your Snyk dashboard.
Procurement and compliance are the hardest piece. SOC2 auditors, FedRAMP packages, and enterprise security questionnaires all assume CVE counts mean something. They don't, not anymore, and the gap between that reality and audit reality is where engineering teams burn quarters chasing zeros. The honest answer — 'this CVE doesn't apply to our usage and we have a documented analysis' — is correct but expensive to defend. Building that muscle now, while the CVE database is merely noisy rather than fully poisoned, is cheaper than building it under audit pressure later.
The coordinated-disclosure regime had a 25-year run and produced real value when researchers and maintainers were roughly matched in effort and competence. That equilibrium is gone, killed by the same automation tailwind that killed the cold-email-to-inbox ratio. Valsorda isn't proposing we abandon security work — he's proposing we stop pretending the protocol designed for human researchers in 2001 fits the LLM-driven submission flood of 2026. Expect more major projects to follow curl and the kernel in publishing 'we don't do embargoes by default' policies through 2026, and expect the CVE database itself to either reform its assignment criteria or lose credibility with the maintainers it depends on for validation.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.