禁令的终结：AI 如何打破漏洞披露安全披露文化

最近的 "Copy Fail" 漏洞是一个典型的案例，展示了网络安全范式的转变。当一名研究人员分享了一个 Linux 网络漏洞的补丁时，他们遵循了传统路径：私下通知安全工程师，同时向公共仓库推送一个静默修复。目标是在修复程序传播期间保持漏洞性质的 "embargoed"（禁令状态）。然而，在几小时内，其他研究人员注意到了该提交，推断出了安全影响，并公开了该缺陷。

这一事件凸显了两种长期存在的漏洞文化之间日益增长的紧张关系——并表明两者都正因人工智能的加速而变得过时。

两种冲突的文化

从历史上看，安全社区在漏洞披露方面主要遵循两种哲学：

协调披露 (Coordinated Disclosure)： 最常见的企业方法。研究人员发现漏洞后，私下通知厂商，并给予一个窗口期（通常为 90 天）来开发和部署修复程序，然后再公开细节。其前提是该窗口期足够长，以便厂商采取行动，但又足够短，以防止研究人员长期持有该发现。
"Bugs are Bugs" (Linux 方法)： 在 Linux 内核社区很常见，这种哲学认为，如果代码正在做错误的事情，就应该立即修复。其希望在于，通过不明确地将修复程序标记为 "security patch"（安全补丁），使其融入到成千上万个其他提交的噪声中，从而为管理员提供更新时间，而不会提醒攻击者注意特定的漏洞。

为什么 AI 改变了局面

这两种文化都依赖于一个特定的假设：发现漏洞——或从补丁中推断出漏洞——的成本足够高，从而能创造出有意义的时间缓冲。AI 正在使这种缓冲消失。

"静默修复" 的终结

对于 "Bugs are Bugs" 文化，其假设是像 Linux 内核这样的大型项目中的信噪比太低，攻击者无法找到每一个与安全相关的提交。AI 改变了这一点。LLM 现在可以实时、廉价且有效地评估通过仓库的每一个提交。

正如一位社区成员所指出的，当一个 AI agent 可以被提示问询 "Does this look like a security patch?"（这看起来像是一个安全补丁吗？）并在几秒钟内得到正确答案时，"人们不会注意到"这一假设就失效了。静默修复的假象已经消失；任何合并到主线的提交现在都是透明的披露。

禁令的崩溃

协调披露的 90 天窗口期也在失效。在 Copy Fail 案例中，第二名研究人员在第一份报告发布仅九小时后，就独立发现了相同的漏洞。随着 AI 辅助扫描的出现，一个漏洞除了被一个人知道之外，在三个月内对所有人保持未知的概率正在大幅下降。

长期的禁令可能会实际上增加风险。它们可能会为厂商营造一种虚假的安全感，并限制能够参与修复工作的专家数量。当窗口期过长时，第三方独立发现漏洞的风险——并且他们可能缺乏对 90 天禁令的耐心——就成为了一个关键的失效点。

超越披露：稳定性的第三种文化

虽然最初的讨论集中在披露，但其影响延伸到了我们如何维护软件。第三种文化——"stable version"（稳定版本）文化——也正受到威胁。许多组织优先考虑稳定性，延迟升级以避免破坏性变更。然而，如果每一个非最新版本的版本都可以被轻易地被 AI 扫描并利用，那么 "slow and steady"（稳扎稳打）的方法就变得难以为继。

正如一位评论员所言，像 Debian 这样以稳定性及其较旧的代码库为傲的项目，可能需要彻底改革其哲学。留在旧版本上的成本不再仅仅是技术债；它是一个向自动化利用程序发出的公开邀请。

迈向新的安全态势

如果漏洞从发现到被利用的时间正在缩减至零，那么行业必须将其重心从 防止披露 转向 加速修复。

Token 的军备竞赛

我们正在进入一个安全是计算能力的军备竞赛时代。防御者必须使用 AI 来修复的速度比攻击者使用 AI 来利用的速度更快。这需要软件供应链的根本转变：

自动化补丁周期： 从缓慢、手动的验证过程转向 AI 驱动的 CI/CD 管道，使其能够在几小时内（而非数月）将漏洞报告转化为 QA-ready 的补丁。
缩短禁令期： 转向极短的披露窗口，以反映 AI 发现的速度。
依赖项 "Warmups" (预热)： 从 "cooldown"（冷却期）转向 "warmups"（预热期），即快速集成更新以保持在利用曲线的前端。

结论

几十年来，安全社区一直相信隐蔽性——无论是通过 90 天窗口期还是静默提交——可以赢得时间。AI 揭示了，隐蔽性是一种我们再也无法负担的奢侈品。唯一的剩余防御手段是速度。目标不再是隐藏漏洞，而是要在 AI 在另一端发现它之前将其堵塞。