AI 正在瓦解两种安全漏洞文化

原文来源：Jeff Kaufman — 一位安全工程师观察到，AI 辅助的漏洞扫描正在同时瓦解"协调披露"和"静默修复"两种安全文化，而新的规则尚未建立。

上周 Linux 内核爆出一个叫 "Copy Fail" 的高危漏洞。Hyunwoo Kim 当天就提交了修复补丁，走的是 Linux 社区标准的处理流程：把安全影响同步给一个封闭的 Linux 安全工程师邮件列表，同时公开提交修复代码，但不公开说明这是一个安全漏洞。目标很简单——利用"信息禁运"争取几天时间：知道内情的人默默修，普通用户尽快打补丁，但谁也不声张。

但有人注意到了这个提交，看出了背后的安全含义，直接公开了。禁运被迫提前结束，细节全部曝光。

这件事本身不算特别。特别的是，类似的剧本正在越来越频繁地上演，而 AI 是背后的加速器。

两种漏洞文化的碰撞

软件安全领域长期存在两种处理漏洞的思路，各自有成熟的社区和规则。

协调披露 是目前最主流的做法。发现漏洞后先私下通知维护者，给一段修复窗口期（通常是 90 天），修复发布后再公开细节。目标是让用户在漏洞被公开之前就已经打好了补丁。

静默修复 在 Linux 内核社区更常见。逻辑是：内核代码里任何"不该做的事"都可能被利用，所以发现就修，不刻意强调安全属性。提交记录里只写 "fix race condition" 或 "correct boundary check"，不提 CVE、不提安全影响。 hope for the best——希望没人注意到。

两种文化的前提都是同一个假设：发现漏洞的速度很慢，窗口期足够长。

AI 把这个前提彻底推翻了。

为什么两种文化同时失效

静默修复失效的原因很直接。

过去安全修复混在大量日常提交里，信号被噪声淹没，专门盯着看的人不多。但现在 AI 可以在几小时内扫描数千个提交，识别出哪些改动涉及内存边界、权限检查、竞态条件——这些正是安全补丁的典型特征。信号噪声比大幅提高，"假装是普通 bug" 的策略越来越不管用。

Jeff Kaufman 做了一个快速测试：把 Linux 的一个真实安全修复提交丢给 Gemini 3.1 Pro、ChatGPT-Thinking 5.5 和 Claude Opus 4.7，三个模型都立刻识别出这是安全补丁。如果只给 diff 不给上下文，Gemini 仍然确信这是安全修复，GPT 认为大概率是，Claude 认为可能不是——但没有一个模型完全忽略。

这意味着，未来攻击者完全可以用 AI 自动化监控主流项目的提交流，实时筛选出潜在的安全修复，然后逆向分析漏洞原理。静默修复从"希望没人注意"变成了"祈祷攻击者没来得及分析"。

协调披露也在失效，只是方式不同。

90 天窗口期的前提是：这段时间内不太可能有其他人独立发现同一个漏洞。但 AI 辅助的漏洞扫描团队数量在快速增长，同一个漏洞被多组人同时发现的概率大幅上升。

Copy Fail 漏洞就是个例子。Kim 提交修复后仅仅 9 小时，Kuan-Ting Chen 就独立报告了同一个漏洞。如果按 90 天窗口期算，这 9 小时连预热都算不上。

更麻烦的是，禁运本身可能增加风险。它制造了一种"不紧急"的假象——维护者知道但用户不知道，补丁优先级被低估。而攻击者一旦通过 AI 扫描发现了修复线索，反而获得了信息优势：他们知道漏洞存在，而防御方还在按"正常节奏"推进。

可能的出路

两种传统机制同时失效，但新的共识还没有形成。

一个可能的方向是极短禁运期。既然 90 天太长、9 小时都可能被独立发现，那干脆把窗口压缩到 24-48 小时。AI 既加速了攻击者也加速了防御者——补丁可以更快写好、更快测试、更快发布。短禁运的前提是 CI/CD 和发布流程足够快，否则只是提前公开而已。

另一个思路是完全透明。既然藏不住，不如直接公开所有安全修复，把精力放在让补丁到达用户的速度上。Chrome 和 Firefox 某种程度上已经在这么做：固定周期发布安全更新，不刻意隐藏但也不多宣传。用户习惯了定期更新，漏洞公开与否对攻击窗口的影响被稀释。

还有一个更激进的观点：漏洞本身不再是最可怕的事，响应速度才是。 在 AI 辅助攻防的背景下，"有没有漏洞"几乎是个确定性事件——复杂软件必然有漏洞。关键变成：发现后多快能修、多快能推送到用户。这更像是公共卫生领域的思路——流感每年都有，重点在疫苗分发和医疗响应，而不是消灭病毒。

对开发者的实际影响

如果你是开源项目维护者，现在应该考虑几件事。

发布节奏比保密更重要。 与其花精力设计完美的禁运流程，不如把 CI/CD 管道优化到能在几小时内发布补丁。快速发布能力本身就是最好的安全策略。

提交记录要诚实但不用过度暴露。 完全不说修复性质已经没意义了，但也不必在提交信息里写利用细节。"Fix use-after-free in packet handler" 足够让 AI 识别出这是安全修复，但不会直接给攻击者提供武器。

考虑加入自动安全扫描。 既然攻击者会用 AI 扫描你的提交，你自己也应该用。GitHub 的 Dependabot、CodeQL，或者商业工具如 Snyk，都可以作为第一道防线。至少在被别人发现之前，你自己先知道。

总结

AI 没有改变漏洞的本质，但改变了发现漏洞的速度和规模。两种历史悠久的安全文化——协调披露和静默修复——都是建立在"发现很慢"这个假设上的，而这个假设已经不存在了。

新的规则会是什么，现在没人说得清。但可以确定的是，继续假装 AI 不存在、按老节奏走 90 天流程，或者继续指望"没人注意"来保安全，都是越来越危险的选择。

对普通开发者来说，最务实的应对是：接受漏洞必然存在的事实，把全部精力放在缩短从发现到修复到用户更新的时间线上。在这个新世界里，速度比保密重要得多。