AI 时代的开源补丁鸿沟：发现速度已超过修复速度

这是什么？

在 2026 年上半年，AI 系统开始以机器的速度报告开源软件中的漏洞，而维护这些软件的人无法以同样的速度修复。2026 年 7 月 2 日，Help Net Security 综述了 Tuskira 对 Anthropic 的 Claude Mythos Preview 协调披露计划的研究：该计划在今年春季约九周内梳理了超过 23,000 条开源代码路径，并把经过验证的发现分发给相应的项目。该计划共报告了1,596 个已验证漏洞，分布在数百个项目中。六家外部安全公司在发现到达维护者之前进行了分诊，并在其抽查的子集上确认了 90.8% 的真阳性率——因此这个数量反映的是真实的缺陷，而非模型噪声。

问题出在之后。发现的速度约为每天 25 个已验证漏洞；而被记入的修复更接近每天 1.5 个。Tuskira 将这种失衡浓缩为一个数字——发现与修复之比约为 16.5 比 1——并将不断扩大的积压称为”漏洞赤字”。这不是一次攻击，而是披露与补丁经济的结构性转变，它改变了任何基于开源依赖交付软件者的规划前提。我们报道它，是因为其防御意义具体而紧迫。

工作原理

这一鸿沟是若干延迟的叠加，每一项单独看都很平常。维护者在”入口”处反应迅速：确认一份报告的中位时间接近一天的五分之一。但确认与修复之间相距甚远。在快照时刻，只有约 6% 的已披露漏洞在上游带有补丁（研究者将其视为下限，因为部分补丁是悄悄发布的），而约 95% 根本没有公开公告。

在下游，还会累积更多延迟。公告数据库需要时间吸收修复，商业扫描器需要时间刷新，企业需要时间在补丁进入生产前进行测试。由于大多数漏洞管理项目只有在存在公开公告后才真正开始工作，从私下披露到企业部署修复的跨度，按报告的结构性估算，约为三到五个月。仅补丁验证一项，对普通语言包通常就需要两到六周——对嵌入式、密码学或受监管的组件则更长——在这段时间里，缺陷可能已经公开，利用工具可能已在流传。

此外，一个上游发现很少只对应一条告警。ImageMagick 中的一个缺陷可能传播到十八个或更多的下游软件包变体，而发行版重建会把仅源码的修复带到许多独立的分发渠道。对防御方真正重要的数字，是生产环境中每一个可达的受影响实例，而这个总数比上游计数所暗示的要高。

这种不对称的”供给侧”如今正在被工业化。2026 年 6 月 22 日，OpenAI 推出了 Patch the Planet，这是与 Trail of Bits（以及 HackerOne 和 Calif）共同发起的 Daybreak 计划，将前沿模型和其 Codex Security 工具与专家人工审查结合，明确是为了减轻而非加重维护者的负担——工程师在发现到达维护者之前，先进行复现、去重、重新评级并修复。SecurityWeek 报道称，同一周内 OpenAI 有意将重心从”发现”转向”让补丁落地部署”。这一认知颇具意味：如今发现问题被认为比修复问题更容易。

为什么重要

暴露窗口在扩大，而非缩小。 多年来，隐含的默契是大多数缺陷未被发现，从而给资源不足的项目留出余地。AI 侵蚀了这一余地：缺陷浮现的速度快于被修复的速度，因此在任何时刻，处于”已知但未修复”状态的缺陷都比以往更多。OSS-Fuzz 在九年间记录了超过 13,000 个漏洞；而单个 AI 计划在极短的时间内就触及了该语料库中相当可观的一部分，并且还有更多发现项目正在上线。

CVE 信息流来得太晚。 在快照时刻，这些发现中约 95% 没有公开公告，因此等待 CVE 才行动，等于在有用信号已经出现之后才行动——这些信号出现在上游提交、透明日志变更以及公告中被致谢的安全公司之中。

数量不等于优先级。 每个计划每天两打的新发现，会淹没任何把每份报告都当作紧急事件处理的团队。若没有办法判断在你自己的环境中什么才真正重要，赤字就会沦为无法管理的噪声。

防御措施

具体数字来自单个计划，但这些运营层面的转变，适用于任何消费或维护开源的人。

1. 以发现的节奏运作，而不仅是以修复的节奏。 假设你依赖项中”已知但无公告”的漏洞如今已多于带 CVE 的漏洞。与其等待公告数据库，不如监控关键依赖的上游提交、发行说明和透明日志。

2. 把打补丁当作决策问题，而非排队队列。 Tuskira 的模型让每个发现经过四个问题：易受攻击的代码路径是否真的在生产中运行、谁能触及该暴露实例、是否有主动利用的迹象、以及现有控制是否已将其阻断。在他们的示例中，一个看似威胁 1,200 个实例的 nginx 严重缺陷，最终收敛为三个既公开、又无需认证、且缺少 Web 应用防火墙的实例。紧急处置投向这三个；其余进入分级通道或有记录的延后处理。

3. 在需要之前先摸清依赖清单。 一份及时的软件物料清单（SBOM），辅以可达性和暴露面数据，才能把发现的洪流变成一份短名单。看不见的东西无法分诊。

4. 增加补偿性控制以缩短你的有效窗口。 在补丁需要数周验证之处，先减少暴露：限制网络可达性，添加 WAF 或输入校验规则，并强化对外实例的认证，使公开的缺陷不至于同时又是无需认证的。

5. 对维护者而言：坚持要求经过验证、去重且有人工审查的报告。 Patch the Planet 的模式——研究者复现证据、去除重复、重新评估严重性并起草补丁，然后才让任何内容到达维护者——正是应向任何 AI 辅助披露计划所要求的范式。未经过滤的模型输出，只会加重它声称要解决的积压。

状态

项目	参考	日期	备注
”AI 补丁鸿沟”分析	Help Net Security / Tuskira	2026-07-02	1,596 个已验证漏洞；发现/修复之比约 16.5:1
Patch the Planet 启动	OpenAI / Trail of Bits	2026-06-22	AI + 专家审查协助维护者修复开源
重心转向修复	SecurityWeek	2026-06-23	OpenAI Daybreak 将重点从发现转向打补丁

一句话总结：AI 已让发现开源漏洞变得又快又便宜，而修复和部署它们仍然缓慢且依赖人力——因此你所依赖软件中”已知但未修复”的缺陷数量正在增长。 持久的启示是防御性的：不要再等待 CVE 信息流，盘点生产环境中真正运行的东西，并按可利用性和暴露面而非报告数量来排定优先级。