你无法通过逐个修复漏洞来摆脱vulnpocalypse

# 你无法通过修 Bug 走出漏洞末日 · Alex Gaynor 来源：https://alexgaynor.net/2026/jul/15/you-cant-bugfix-your-way-out-of-the-vulnpocalypse/ 2026年7月15日，星期三 （我在 Anthropic 工作。） 对于安全工程师来说，最重要（也是最困难！）的问题之一就是：“这个代码库中存在多少漏洞？” 你可以知道自己已知但尚未修复的漏洞数量。也许你能通过一些推算，根据历史上漏洞从引入到发现的时间，估算出存在但未被发现的漏洞数量——但这更难。尽管在回答“存在多少未知漏洞”时存在固有的高度不确定性，我们往往倾向于假设昨天新发现的漏洞率，明天也会同样如此。但有些日子你一觉醒来，发现自己已经不在堪萨斯了。我记得当初基于覆盖引导的模糊测试（AFL 和 libFuzzer）变得足够强大，基本上任何做成解析器形状的东西都肯定会产出相当数量的漏洞。而现在，AI 漏洞末日（vulnpocalypse）已经到来，而且它还能生成可用的漏洞利用代码。 漏洞末日的构成方式是：一项新的技术创新使得（或间接导致）在现有软件中发现大量漏洞，从而推翻之前一切关于现有漏洞数量的假设和信念。当漏洞末日来临，公司、开源项目和软件消费者被迫以前所未有的速度进行识别、分类、修复、分发和打补丁。由于漏洞数量过多，现有流程崩溃。再也不可能用原有的资源分配和流程来修复所有漏洞。 这种新模式——新技术创新颠覆核心假设并需要新方法——就是文献中所说的“根本性惊奇”（fundamental surprise）。我的一些朋友写了一本关于这个主题的书（https://crisisengineering.layeraleph.com/crisis-engineering-the-book/）。漏洞末日的失败模式是：漏洞堆积如山，分类过程严重滞后，开源维护者倦怠，修复漏洞成了随机抽样并祈祷遗漏的漏洞不被利用。有些团队加倍努力逐个修复漏洞，排挤掉其他类型项目的工作，只求尽可能修补所有能找到的漏洞，直到恢复到之前的漏洞稳态。这实际上是同一枚硬币的两面，只是成功程度不同。 幸运的是，还有更好的方法。首先要认识到，大量漏洞本质上具有相同的形态和近因，并且可以通过系统性修复来解决。不是所有漏洞，但很多都是如此。 多年以前，我被拉去帮助一个团队应对他们自己的个人漏洞末日。那是一个旧的 VB Script 代码库，大约几十万行代码，一个处于维护模式的开发团队。那是一种代码库，**每一条** SQL 语句都容易受到 SQL 注入攻击，每一个嵌入到 HTML 中的变量都是一个 XSS 漏洞。还有其他漏洞，但单纯从数量上看，XSS 和 SQLi 轻松占了 90% 以上。 SQLi 的模式在旧应用中很常见：每个页面都有自己定制的打开数据库连接的代码，SQL 通过字符串拼接手工打造。修复方法不是去逐条手工检查每个 SQL 查询是否脆弱，而是引入一个新的 `SQLExecute` 函数，它接受一条 SQL 查询和一个参数数组，并正确地处理查询。然后代码库中的每一条 SQL 查询都被迁移到 `SQLExecute`（许多通过简单的正则表达式完成）。之后，一条简单的规则确保了不会出现回归：除了调用 `SQLExecute` 并传入字符串字面量外，禁止以任何其他方式执行 SQL 查询——这条规则可以在 CI 中轻松强制执行。最终结果是在一两周内修复了数千个漏洞，并且漏洞保持修复状态，不会再被重新引入。 这种将代码库限制为仅使用安全模式的做法并不新奇。为了防止 XSS，Django 的模板会自动对模板中插值的任何变量进行 HTML 转义，React 则区分文本内容和标记。这正是内存安全语言防止缓冲区溢出和释放后使用漏洞的方法。不幸的是，人们往往不采取这种思路。 对这种思维方式的一个常见反对意见是：“这听起来不错，但我已经疲于应付简单的 Bug 修复了，你还要我花时间做大型技术变革？”这是一个非常合理的问题。漏洞末日的本质就是你将被漏洞的洪流淹没——如果不是这样，那就不叫漏洞末日了！在这种背景下，你需要退后一步，问自己：“我们如何摆脱这种局面？”答案是，你必须在系统性预防整个类别的漏洞上做出基础性投入，即使这意味着修复单个漏洞的延迟会略高。虽然在非常短期内这可能很痛苦，但从更长时间尺度来看，这是至关重要的。当然，像任何好的工程项目一样，你应该将工作结构化为可增量交付、能产生价值的部分，而不是一个永远无法实现的宏大爆炸式改革。 从根本上说，许多人对于漏洞研究在软件开发生命周期中的目的有错误观念。漏洞研究（我指的是在拉取请求已经合并后识别漏洞的任何活动）的目的，是找出工具和抽象层的缺口，以便改进它们。识别出个体 Bug 来修复是你发现这些缺口的机制，它之所以有价值，是因为漏洞的存在证明了缺口的存在。如果你只用安全研究识别的漏洞来修复它们，你就浪费了一个巨大的机会。 并非每个漏洞都适合“简单地说‘阻止所有可能的实例’”这样的解决方案。然而，实际上每个漏洞都可以通过改进工具和抽象层来显著降低其再次出现的可能性。而且，适合系统性修复的漏洞多得令人沮丧。看看 2025 年已知被利用漏洞（KEV）的 2025 年 TOP 原因（https://cwe.mitre.org/top25/archive/2025/2025_kev_list.html），前三个中的全部，以及前十个中的六个，都适合系统性修复。 如果你看到漏洞末日正朝你袭来，你能做的最重要的事情就是将其引导为系统性修复。否则就是让危机白白浪费，并在大量漏洞的重压下被淹没。