漏洞报告不再特殊
作为一名在公开环境中工作的开源维护者，保持心智健康的要诀之一是意识到：每一个 Issue、每一个 PR、每一份反馈都是礼物，而不是义务。你可以接受它，忽略它，部分采纳它，或者完全不理会。
除了一种情况……
多年来，在我担任 Go 安全团队负责人期间，我一直告诉新团队成员——这个规则不适用于漏洞报告。不，漏洞报告是特殊的。安全研究员通过私下报告而非完全公开披露的方式帮助我们，这本身就是一种恩惠，所以我们欠他们一些东西——这与 Issue 跟踪器上的普通问题不同。
不同的项目有不同的策略，但普遍的期望是及时响应和署名致谢。我们应该快速确认报告，展开调查，向报告者同步进展，最终在发现中给予他们荣誉。
为什么？因为报告者是在为我们提供服务，而不是请求我们提供服务（比如修 bug 或实现功能）。作为响应速度和署名致谢的交换，他们提供了宝贵的洞见，以及我们需要的保密性——让我们能在攻击者利用漏洞之前推送修复。
归根结底，这一切源于我们对用户的责任。安全研究员并不特殊，特殊的是他们的洞见和保密性，我们依靠这些来保护用户的安全。忽视安全报告意味着你不在乎用户的安全，这理应是一件令人羞愧的事。
但是……
现在是 2026 年，这些前提已不复存在。
LLM 已经和几乎任何安全研究员一样优秀，而且任何人都可以运行它们。维护者可以运行它们，攻击者也可以运行它们。
洞见不再是稀缺和宝贵的了。现在的瓶颈不是发现潜在问题，而是判断哪些问题是真实存在的。除非已经建立了信任关系，否则外部研究员无法有意义地参与这个研判过程——在 LLM 的输出中筛选，或者在 security@ 收件箱中挑选，两者的信噪比大致相同。
保密性、禁运期和协调披露也不再像过去那么重要。攻击者不需要阅读公开披露的文章来了解漏洞：他们可以问自己的 LLM——事实上，他们和防御者一样面临着研判瓶颈。
漏洞报告曾经特殊的那段岁月可能已经结束了——尽管这感觉很奇怪、很不舒服。研判、快速修复、以及一如既往的——预防——才是现在的工作。而我们也许都应该搞清楚如何在 CI 中运行 LLM 分析。
各方评论
这篇文章很快引发了一些有趣的讨论，这让我有机会补充一些细节。
在 Bluesky 上，Avery Pennarun 指出情况还会再次发生变化。我不确定我是否同意。在发现漏洞的能力上确实发生了一次阶跃变化，但唯一稳定的结果（一旦我们到达那里）是发布时包含更少的漏洞。到那时会有一个新的更高标准，发现问题又将变得困难。我不确定我们是否应该为短期动态做优化。当前的动态至少会持续到模型持续变得更好。老实说，我不知道在那之后这个职业会是什么样子，所以整篇文章更像是一个当下的观察，而不是一个长期的预测。
在 Lobsters 上，Frederik Braun 指出仍然有一些漏洞报告是特殊的。特殊的漏洞报告应该被特殊对待，防御者需要努力改进验证方法并发布威胁模型，这样人们才能达到（并验证）一个更高的标准，来界定什么是优质的漏洞报告。
我同意，无论正式还是非正式，都需要有一个处理特殊报告的流程：那些极高严重性的报告，那些来自高度可信来源的报告。也许安全团队的下一个任务是学会快速将报告分类为特殊和普通两类。
在 Hacker News 上，William Woodruff 确认大多数报告是真实的，而且已不再特殊。我同意这一点。"漏洞末日"的后果之一是筛选噪音变得更加困难了：我每周要研判十几份报告，其中很多在"真实"的意义上反映了真实的缺陷，但对典型用户的影响却不明确。这在中位漏洞报告中一直都是如此，但如今的数量意味着我现在大幅度地远离协调披露。另一面是，由于这些 bug 对 LLM 来说是"浅显的"，现在比以往任何时候都更容易管理漏洞报告项目中表现最差的参与者——如果有人给你发垃圾报告，你可以直接封禁他们，等待下一个更完善的 LLM 针对同一个漏洞发来更好的报告。想象一下，仅仅一年前你还能随意封禁研究员！
订阅与关注
更多内容请订阅，或在 Bluesky 上关注我 @filippo.abyssdomain.expert，或在 Mastodon 上关注我 @filippo@abyssdomain.expert。
照片的故事
几周前，像往年一样，我参加了 CENTOPASSI——一场 GPS 追踪的摩托车比赛，需要精心规划、100 个坐标点、1700 公里的二级公路，耗时三天半。它总是带我去一些不可思议的地方，比如普利亚大区这座废弃的铝土矿。
我的工作得以开展得益于 Geomys——一个由专业 Go 维护者组成的组织，由 Ava Labs、Teleport、Datadog、Tailscale 和 Sentry 资助。通过他们的顾问合约，他们确保了我们的开源维护工作的可持续性和可靠性，并直接获得我的专业知识以及 Geomys 其他维护者的服务。（了解更多请阅读 Geomys 公告。）
以下是其中一些支持者的话：
Teleport — 过去五年，攻击和入侵已从传统的恶意软件和安全漏洞转向通过社会工程、凭证窃取或钓鱼来识别和入侵有效用户账户和凭证。Teleport Identity 旨在通过访问监控消除薄弱访问模式，通过访问请求最小化攻击面，并通过强制访问审查清除未使用的权限。
Ava Labs — 我们 Ava Labs 是 AvalancheGo（与 Avalanche 网络交互最广泛使用的客户端）的维护者，我们相信开源加密协议的可维护开发和可持续维护对于区块链技术的广泛采用至关重要。我们很自豪通过持续赞助 Filippo 及其团队来支持这项必要且具有影响力的工作。
我在离开 Google 时将这个角色交到了可靠的人手中，所以尽管我仍然参与 Go 项目的维护，但这并不代表 Go 安全团队的官方立场。↩
在漏洞报告处理与行为准则执行之间容易变得混乱。如果某人也违反了行为准则，但却报告了安全漏洞，你会怎么做？无视它？秘密修复？现实是这没有完美的解决方案。这取决于行为的恶劣程度、是私下行为还是影响了社区、以及处理 security@ 收件箱的团队成员有多少资源。这是一份有趣的工作。↩
实际上，披露实践有一段复杂的历史。在另一个时代，报告安全问题确实是危险的：善意的研究员常常面临法律威胁或起诉。正是完全披露运动让整个行业意识到这种做法是多么适得其反和不合理。协调披露（或者"负责任的披露"——我不喜欢这个带道德色彩的说法）交易的一部分是——隐式或显式地——承诺不去追究研究员的责任。庆幸的是，在 2026 年的开源现实中，这点基本上不再相关：没有研究员会害怕因报告安全漏洞而被起诉，也没有项目应该暗示起诉是其文档化报告策略之外的替代选项。↩
嗯……算是吧。但再给 1-3 个月，开源模型就会追上来了。↩
就在几天前，在 Geomys 的静修会上，我还在争论 curl 暂停漏洞报告渠道一个月的做法有些过分——因为把安全报告丢在地上不管，从直觉上就是错的。然而，在我写这篇文章的时候，我找不到任何论据来说明处理漏洞报告是保护用户的最佳时间利用方式。时代在变，我们的工作方式也必须随之改变。↩
原文：Vulnerability Reports Are Not Special Anymore — Filippo Valsorda
