这篇文章探讨了在漏洞披露中存在的两种文化——“协调披露”和 Linux 社区常见的“先修复、少声张”——以及人工智能（AI）如何打破这两种模式。核心论点是，由于 AI 能快速从公开的补丁中识别漏洞，悄悄修复的策略已不再有效。同时，传统的长时期保密（embargo）也充满风险，因为 AI 辅助的团队很可能独立发现同一漏洞。最终的结论是，未来可能需要更短的披露窗口，并利用 AI 同时加速防御和修复。
两种漏洞披露文化的冲突
文章以 Linux 内核的一个漏洞（Copy Fail/ESP）为例，引出了两种处理方式的矛盾。
Linux 的传统做法: 开发者发现漏洞后，会私下通知一个小的安全工程师圈子，同时在公开的代码库中悄悄地、高效地修复。目标是在不引起注意的情况下，让补丁先行发布，从而对漏洞信息形成事实上的“禁运”(embargo)。
这次发生的情况: 补丁发布后，有人立刻注意到了变更并意识到其安全影响，随之将其公之于众。这使得原定的“禁运”立即失效。
这一事件凸显了两种不同安全理念之间的紧张关系。
两种主流的披露文化
“协调披露”文化 (Coordinated Disclosure) 这是计算机安全领域最常见的方法。当你发现一个安全漏洞时，你会私下通知维护者，并给他们一段固定的时间（通常是 90 天）来修复它。目标是在漏洞细节被公开之前，确保修复方案已经就位。
“漏洞就是漏洞”文化 (Bugs are Bugs) 这种文化在 Linux 社区尤为普遍。其理念是，内核的任何异常行为都可能被利用，因此应该尽快修复，无需大张旗鼓。他们寄希望于在海量的代码变更中，安全补丁不会引起注意，从而为系统管理员争取打补丁的时间。
这两种方法都在面临新的挑战，尤其是在 AI 技术加速发展的背景下。
AI 如何改变游戏规则
过去行之有效的方法，现在正变得越来越不可靠。
“悄悄修复”的失效: 这种方法从未完美，但在 AI 面前，它更是个大问题。AI 越来越擅长在无数的代码提交中自动评估和发现安全补丁。一个简单的实验表明，当前主流的 AI 模型在被提供补丁代码后，能立即判断出这很可能是一个安全修复。这使得“隐藏在众目睽睽之下”的策略变得不可能。
长“禁运期”的风险: 传统的长禁运期（如 90 天）建立在一个前提上：在此期间，不太可能有其他人发现同一个漏洞。但现在情况变了。
- 重复发现: 随着大量 AI 辅助的团队扫描软件漏洞，多个团队在短时间内独立发现同一漏洞的可能性大大增加。例如，在 ESP 漏洞被报告后仅九小时，就有其他人独立报告了同一个问题。
- 虚假安全感: 长时间的保密会制造一种“事情不紧急”的错觉，并限制了能够参与修复的人员范围，反而可能增加风险。
未来的方向：更短的披露窗口
面对 AI 带来的挑战，作者认为需要调整策略。
我不知道如何解决这个问题，但个人认为非常短的禁运期似乎是一个好方法，而且随着时间的推移，它们需要变得更短。
幸运的是，AI 不仅能帮助攻击者，同样也能加速防御者的响应速度。这意味着，AI 可以帮助开发和部署修复方案，使得过去因时间太短而无意义的“超短禁运期”变得可行。未来的漏洞处理流程，将是在 AI 辅助下的一场速度竞赛。