修复漏洞的PR刚提交几分钟，探测请求就出现在日志里了

剑桥大学计算机科学教授、OCaml编译器核心维护者Anil Madhavapeddy最近写了一篇文章，讲的是他自己修一个路径遍历漏洞的经历。补丁本身并不复杂，按老规矩，流程该是私下修好、通知受影响的用户，之后再发公开安全公告。但他注意到，把修复这个问题的拉取请求提交上去之后，才过了几分钟，Web服务器的日志里就冒出了与这个漏洞模式一模一样的探测请求。

传统的漏洞披露流程建立在保密的前提上，假设把技术细节藏住就能保护用户。AI智能体把这个前提动摇了：它能凭有限的线索自己把漏洞研究出来。在最近的一项研究里，一个基于GPT-4的智能体在拿到CVE描述之后，成功利用了15个漏洞基准中87%的漏洞；没有描述时，这个比例只有7%。两个数字之间的落差说明了问题——只要有描述，它就从基本失败变成基本成功。

Madhavapeddy的推论比这更让人不安。他认为触发条件不必是一份正式的CVE描述：只要有人在搜索某一类漏洞，不管表现为邮件列表里的一个提问、孤立分支上一次异常提交，还是某种上下文泄露，都足以提醒别人的智能体，让它们把漏洞利用代码写出来。他把这个变化形容为“漏洞经济学”开始对开源软件维护者不利。

负担已经在数字上显现。开源项目rclone一个月收到的安全报告超过40份，而它整个头十年收到的报告大约只有20份。修漏洞和写漏洞报告这两件事的成本，被AI同时压低了，代价是维护者要处理的队列变长了好几倍，而队列里每一项的响应时间又被压缩到了分钟级。

这让开源维护者陷进一个两头堵的局面。Chainguard开发者关系负责人Adrian Mouat说，光是把一个用于修复的拉取请求建出来，就已经让项目和用户处在危险里，因为攻击者甚至可以在修复版本发布出来之前，就把漏洞利用程序写出来并用上：用户已经暴露在风险里，却对此无能为力。他提到一种可能的走向——项目先在发布源代码之前发布软件版本，可那样又破坏了开源软件的基本原则。

开源安全这边能做的事情不多，但方向比较明确。Madhavapeddy的建议包括开设私密漏洞讨论渠道、加快持续发布的节奏，以及在协议层面引入短期凭证和可撤销能力这类控制手段。核心思路是把安全流程反过来：不再依赖信息隐藏去争取时间，而是承认任何公开信号都可能被立刻利用，转而把“从第一个公开信号到修复可用”这段间隔压到最短。对靠开源组件搭站的团队来说，这条判断同样成立——依赖库出安全更新时，留给你升级的窗口比过去窄得多。