Vulnerability Reports Are Not Special Anymore
A requirement for staying sane while working in public as an open source maintainer is realizing that every issue, PR, and piece of feedback is a present, not an obligation. You can accept it, ignore it, and use it partially or not at all.
Except…
For years, as lead of the Go Security team at the time,1 I’ve told new team members that it doesn’t apply to vulnerability reports. No, vulnerability reports are special. Security researchers are doing us a favor by reporting things confidentially instead of doing full disclosure, so we owe them something, which is not true of regular issues opened on the issue tracker.2
Different projects have different policies, but the general expectations are responsiveness and attribution. We’re supposed to acknowledge reports quickly, investigate them, keep the reporter posted, and eventually credit them with the discovery.
Why? Well, because the reporter is providing us a service, not asking us to provide one (such as a bug fix or a feature implementation). In exchange for responsiveness and attribution, they are offering precious insight and the confidentiality we need to ship a fix before attackers ship an exploit.3
Ultimately, it all stems from our responsibility to our users. The security researchers are not special, the insight and confidentiality are, and we need them to keep our users safe. Ignoring a security report communicates you don’t care about users’ security, and it’s rightly a reason for shame.
Except…
It’s 2026 and none of the premises are true anymore.
LLMs are as good as almost any security researcher, and anyone4 can run them. The maintainers can run them. The attackers can run them.
The insight is not scarce and precious anymore. The bottleneck now is not finding potential issues but assessing which ones are real. Unless there’s already a trust relationship, external researchers can’t meaningfully contribute to that triage process, and picking through an LLM’s output or through a security@ inbox has approximately the same signal-to-noise ratio.
Confidentiality, embargoes, and coordination also don’t matter nearly as much as they used to. The attackers don’t need to read the full disclosure post to learn about the vulnerability: they can ask their own LLM and, in fact, they also probably have the same triage bottleneck as the defenders do.
The years of vulnerability reports being special might be over, as weird and uncomfortable5 as that feels. Triage, rapid remediation, and—as ever—prevention are the job now. And we should all figure out how to run LLM analysis in CI, I suppose.
For more, subscribe or follow me on Bluesky at @filippo.abyssdomain.expert or on Mastodon at @filippo@abyssdomain.expert.
The picture
A few weeks ago, like every year, I ran the CENTOPASSI, a GPS-tracked motorcycle competition involving careful planning, 100 coordinates, and 1700 km of secondary roads over three days and a half. It always takes me to incredible places, like this abandoned bauxite mine in Puglia.
My work is made possible by Geomys, an organization of professional Go maintainers, which is funded by Ava Labs, Teleport, Datadog, Tailscale, and Sentry. Through our retainer contracts they ensure the sustainability and reliability of our open source maintenance work and get a direct line to my expertise and that of the other Geomys maintainers. (Learn more in the Geomys announcement.) Here are a few words from some of them!
Teleport — For the past five years, attacks and compromises have been shifting from traditional malware and security breaches to identifying and compromising valid user accounts and credentials with social engineering, credential theft, or phishing. Teleport Identity is designed to eliminate weak access patterns through access monitoring, minimize attack surface with access requests, and purge unused permissions via mandatory access reviews.
Ava Labs — We at Ava Labs, maintainer of AvalancheGo (the most widely used client for interacting with the Avalanche Network), believe the sustainable maintenance and development of open source cryptographic protocols is critical to the broad adoption of blockchain technology. We are proud to support this necessary and impactful work through our ongoing sponsorship of Filippo and his team.
-
A role I passed on to capable hands when I left Google, so despite still being involved in the maintenance of the Go project, none of this is the official position of the Go Security team. ↩
-
This gets messy quickly at the intersection of vulnerability report handling and Code of Conduct enforcement. If a security vulnerability is reported by someone who is also violating the CoC, what do you do? Do you ignore it? Fix it silently? Realistically, there’s no squaring the circle. It comes down to a judgment call based on how egregious the behavior is, on whether it is private or affecting the community, and on the resources available to the team members servicing
security@. It’s an interesting job. ↩ -
There’s actually a lot of complex history to disclosure practices, and in a different era it was genuinely dangerous to report security issues: well-intentioned researchers were frequently met with legal threats or prosecution. It took the full disclosure movement to make the industry internalize how counterproductive and unreasonable that was. Part of the coordinated disclosure (or “responsible” disclosure, a morally loaded term I dislike) trade was a promise, implicit or otherwise, not to go after researchers. Thankfully, that angle is mostly irrelevant to the reality of open source in 2026: no researcher fears prosecution in reporting a security vulnerability, and no project should even imply prosecution is on the table as the alternative to its documented reporting policy. ↩
-
Welp. Sort of. But give it 1-3 months and the open models will catch up. ↩
-
Just a few days ago, at the Geomys retreat, I was arguing that curl’s month-long suspension of vulnerability reporting channels was going too far, because it feels viscerally wrong to drop a security report on the floor. And yet, as I write this, I have no argument for servicing vulnerability reports being the best way to spend time to protect users. Gotta change to keep up with what the job actually is. ↩