Vulnerability Reports Are Not Special Anymore
Vulnerability Reports Are Not Special Anymore
漏洞报告不再特殊
23 Jun 2026 2026年6月23日
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. 作为一名开源维护者，要在公开环境下保持理智，前提是必须意识到：每一个 Issue、PR 和反馈都是一份礼物，而非一种义务。你可以选择接受、忽略，或者部分采纳甚至完全不予理会。
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. 然而……多年来，作为当时 Go 安全团队的负责人，我一直告诉新成员：这条规则不适用于漏洞报告。不，漏洞报告是特殊的。安全研究人员选择私下报告而非完全公开，是在帮我们大忙，因此我们欠他们一份情；而这对于 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. 不同的项目有不同的政策，但普遍的期望是响应和署名。我们理应快速确认报告、进行调查、随时向报告者通报进展，并最终在发现者名单中给予他们署名。为什么？因为报告者是在为我们提供服务，而不是要求我们提供服务（如修复 Bug 或实现功能）。作为对响应和署名的交换，他们提供了宝贵的见解以及我们所需的保密性，让我们能在攻击者发布利用程序之前发布修复补丁。
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. 然而……现在是 2026 年，上述所有前提都不再成立了。大语言模型（LLM）的能力几乎不亚于任何安全研究人员，而且任何人都能运行它们。维护者可以运行，攻击者也可以运行。这种见解不再稀缺且珍贵。现在的瓶颈不在于发现潜在问题，而在于评估哪些是真实存在的。除非已经建立了信任关系，否则外部研究人员无法对分类（Triage）过程做出实质性贡献，从 LLM 的输出中筛选信息与从 security@ 邮箱中筛选信息，其信噪比几乎是一样的。
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. 保密性、禁令（Embargoes）和协调工作也不再像过去那样重要。攻击者不需要阅读完全公开的披露文章来了解漏洞：他们可以直接询问自己的 LLM。事实上，他们可能也面临着与防御者相同的分类瓶颈。
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. 漏洞报告“特殊”的时代可能已经结束了，尽管这感觉既奇怪又不舒服。现在的核心工作是分类、快速修复，以及一如既往的预防。我想，我们都应该研究如何在 CI（持续集成）中运行 LLM 分析了。
(Note: The article continues with personal updates, sponsorship disclosures, and footnotes. The above covers the core editorial content.)