AI 编程代理正在压缩漏洞披露的安全窗口

Simon Willison2026-08-30 05:01

一个漏洞线索，可能已经足够

剑桥大学计算机科学教授、OCaml 编译器核心维护者 Anil Madhavapeddy 近期观察到一个值得开源社区关注的现象：安全补丁一旦在公开代码仓库中进入讨论，潜在攻击者可能在极短时间内开始尝试利用。

在一次 OCaml 项目相关事件中，按照过去的经验，从发现问题、讨论补丁到正式发布修复版本，通常可以持续数天，一两周内发布新版本也属于合理节奏。

但这一次，补丁进入公开讨论后大约 10 分钟，相关网站就开始收到针对百分号编码路径遍历序列的探测请求。这意味着可能存在自动化系统持续监控公开代码仓库，并快速根据代码变化寻找潜在漏洞。

现代 AI 编程代理已经具备较强的代码分析和漏洞发现能力。一个公开补丁、一段提交记录，甚至只是关于某个 Bug 的模糊线索，都可能为自动化系统提供足够的信息，进一步定位漏洞。

Madhavapeddy 使用自己的 AI 代理进行了相关测试。在 Claude Fable 拒绝执行相关任务后，他切换到 DeepSeek V4 Pro，并展示了代理根据有限线索继续寻找问题的能力。

这里真正值得关注的并不是某一个模型，而是软件安全中的时间窗口正在发生变化：过去维护者可能拥有数天时间完成讨论、协调和发布，现在从漏洞信息出现到外部开始探测，间隔可能被压缩到分钟级。

rclone 维护者 Nick Craig-Wood 描述了类似变化。

据其介绍，rclone 项目最初 10 年通过 GitHub 收到的安全披露大约只有 20 个，而最近一个月需要处理的安全披露已经超过 40 个。

这些报告也并非大量毫无价值的噪声。他估计，大约 75% 的安全报告至少包含一些值得进一步检查的问题。即使已经使用 AI 工具辅助分类、分析并生成待审核的修复方案，大量安全报告依然占用了维护者相当多的时间。

另一个连锁影响出现在 CVE 分配环节。据 Craig-Wood 描述，此前 GitHub 为安全公告分配 CVE 通常需要 2～3 天，现在等待时间已经达到 3～4 周。因此，他不得不在部分修订版本的更新记录中暂时使用 CVE-PENDING。

这些案例指向了一个现实问题：AI 不只是帮助开发者更快修复漏洞，同样可以帮助其他人更快从公开信息中定位漏洞。

传统开源安全流程通常假设维护者在漏洞发现后拥有一定的协调窗口，可以讨论修复方案、准备版本、申请 CVE，再向用户发布更新。

如果自动化代理能够持续监控代码仓库，并在补丁或漏洞线索出现后的几分钟内开始分析和探测，那么这一时间窗口可能已经不足以支撑过去的工作方式。

这并不意味着所有公开补丁都会立即转化为可利用漏洞，但至少从 OCaml 与 rclone 维护者描述的情况来看，AI 辅助漏洞发现正在给开源项目的安全响应速度、漏洞披露机制和维护者工作负担带来新的压力。