一周前，Copy Fail 漏洞曝光。Hyunwoo Kim 随即意识到官方修复并不充分，并在当天提交了补丁。在此过程中，他遵循了 Linux 领域（尤其是网络方向）的标准流程：将安全影响告知特定的 Linux 安全工程师名单，同时在公开渠道高效且低调地修复该漏洞。他的目标是仅公开原始补丁，从而对“存在严重漏洞”这一消息进行“封锁”：即知情者达成默契，在几天内保持沉默。然而，有人注意到了这一变更，识别出其背后的安全含义并将其公之于众。由于消息已经泄露，封锁协议被视为终止，漏洞的全部细节也随之公开。 这一事件揭示了两种不同的漏洞处理方式之间的张力，并引发了关于 AI 加速将如何改变现状的思考。 一方面是“协调披露”文化。这可能是计算机安全领域最通用的方法：发现安全漏洞后私下通知维护者，并给予一定的修复期（通常为 90 天），旨在确保漏洞信息公开前补丁已经就绪。 另一方面是“漏洞即漏洞”文化。这在 Linux 社区尤为常见，其论点是：如果内核执行了不该执行的操作，那么总有人能将其转化为攻击。因此，应当在不引起注意的情况下尽快修复。通常在海量的代码变更中，人们不会注意到这类补丁，从而为机器安装补丁争取时间。 这种方法从未达到完美，而随着 AI 愈发擅长发现漏洞，它正面临严峻挑战。如今安全修复层出不穷，审查提交记录变得极具吸引力：信噪比更高了。此外，利用 AI 对每一项提交进行评估正变得日益廉价且高效。 然而，长期的信息封锁也同样难以为继。过去的检测节奏较慢：如果你发现漏洞并给予厂商 90 天的披露窗口，期间几乎没其他人会发现它。但现在，大量 AI 辅助的团队正在扫描软件漏洞，这种情况已不复存在。在本例中，就在 Kim 报告 ESP 漏洞仅 9 小时后，Kuan-Ting Chen 也独立报告了该漏洞。封锁反而可能增加风险：它们创造了一种虚假的非紧急感，并限制了参与修复的人员范围。 虽然目前尚无定论，但我个人认为短期的封锁似乎是较好的折中方案，且随着时间的推移，这种窗口期需要进一步缩短。幸运的是，AI 在加强攻击方的同时也能加速防御方，这使得原本因过短而无效的封锁期变得可行。