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, 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.

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.

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 anyone 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 uncomfortable 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.

A couple comments

This post rapidly generated some interesting discussion, which gives me the opportunity to add some nuance.

On Bluesky, Avery Pennarun points out things will change again.

I’m not sure I agree. There’s been a step change in ability to find vulns, but the only stable outcome (once we get there) is fewer vulns getting released. When that happens there will be a new higher bar and finding them will be hard again. Unclear we should optimize for the short term dynamics.

The current dynamic will persist at least for as long as the models keep getting better. I honestly have no idea how the profession will look after that, so this whole post is more of a current observation than a long-term prediction.

On Lobsters, Frederik Braun calls out how there are still some vulnerability reports that are special.

Special vulnerability reports should be treated as special and it is on the defender to work on better verification and published threat models such that people can meet (and verify) a new, higher bar for what constitutes a great report.

I agree, whether officially or unofficially there will need to be a process for special reports: the extremely high severity ones, the ones from highly trusted sources. Maybe the next task of security teams is getting good at classifying reports rapidly into special and not special buckets.

On Hacker News, William Woodruff confirms most reports are real, and not special anymore.

I agree with this. One of the consequences of the “vulnpocalpyse” is that it’s become even harder to sift through the noise: I triage well over a dozen reports a week, many of which are “real” in the sense that they reflect a genuine defect but otherwise have an unclear impact on a typical user. This has always been true of the median vulnerability report, but the volume means that I now lean much more heavily away from coordinated disclosure.

One flipside to this is that, because many of these bugs are “shallow” to LLMs, it’s actually easier than ever to moderate the worst participants in your vulnerability program – if someone sends you slop, you can just ban them and wait for the next, better orchestrated LLM to send you a better report for the same vulnerability.

Imagine being able to freely ban researchers just one year ago!

Still on Hacker News, Juho Forsén, one of the most prolific reporters of Go security issues, wrote a long interesting comment that makes the argument that instead we should lean harder into trust relationships with individual researchers. It’d certainly be worth it with Juho, in retrospect, but it’s unclear if it would pay off often enough, in the same way that training new contributors who might leave the project in a month or two is not always worth it.