我今天发布了OCaml的cohttp 6.3.0的安全修复，修复了一个路径遍历问题。补丁本身相当简单，通常情况下，安全程序会私下修复，通知受影响的用户，然后发布公共公告。然而这次，我注意到在打开修复此问题的PR后几分钟内，我的实时web服务器日志中出现了具有相同漏洞模式的探测记录。更糟的是，我发现我可以通过大概了解漏洞的性质来利用我的代理找到这个漏洞，也就是说我本可以在公共补丁发布之前就开始利用它！鉴于仅凭安全问题的传闻似乎就足以使攻击者获得足够的信息来寻找新的漏洞，我们需要改变在开源项目中处理安全响应的方式。 1 漏洞的传闻是新代理利用系统所需的一切 这个特定的报告上周通过Jane Street通过一个Slack频道私下到达，并且是通过Claude Fable发现的。这大大压缩了所有时间线… 1.1 现代安全报告的时间线 在详细检查补丁之前，我将我的Claude指向受影响的代码，看看还有什么潜伏（让我调查路径规范化问题）。Fable由于我没有访问Glasswing的权限而令人沮丧地拒绝了，但DeepSeek V4 Pro满足了我的要求，独立发现了几个相关问题。我的代理也在不到一分钟的时间内极其轻松地创建了一个利用来探测本地实时服务器。在与漏洞报告者就可能的修复进行了一番讨论后，我悄悄地公开了cohttp#1145，以获得更多人的关注。通常来说，这个反馈过程需要几天时间，而在一到两周内发布更新是合理的。然而在大约十分钟内（！）这个网站就开始接收百分比编码的遍历序列的探测，这表明自动化观察者正在监控公共存储库。如果我只花了一分钟就创建了自己的漏洞，那十分钟实际上似乎对于自动攻击窗口的开始而言相当漫长！一个关注软件包存储库的决心很大的攻击者可能会在几秒钟内就开始利用。 1.2 安全禁运不再有效 传统的安全流程涉及对漏洞进行禁运，并假设细节的保密性能保护用户。然而，现今的代理所需要的只是一个广泛的搜索方向，便可以自己进行调查。Fang等人发现，当GPT-4代理获得CVE描述时，它利用了15个漏洞基准的87%，而没有描述时，仅为7%。两年后，平均利用时间为-7天。换句话说，利用现在优于补丁！这个指标在2018-19年约为63天，并在2024年突破了零。一项快速搜索显示，如今有很多类似的案例…… marimo的CVE-2026-39987在9小时内从公告转至首次利用，尽管没有存在任何公开的概念证明，Langflow的CVE-2026-33017则花费了20小时。我们似乎已经跨越了自动化漏洞生成的法尔克镇…… 2026年LLM利用的状态（来源：Vulncheck） 2 漏洞经济现在对OSS维护者是否不利？ 在我看来，我们的安全流程需要某种程度上的反转，因为只需一个人搜索问题类别（可能是一个邮件列表问题，一个孤立分支中的奇怪提交，或是上下文泄漏）就足以警告到其他人的代理，并让他们获得利用代码。这真是疯狂。2026年5月的一篇论文创造了“漏洞经济”一词，并指出瓶颈已转向“防御者修复吞吐量”。LLM们愉快地生成利用代码，但我们抵御这些利用的能力未必在改善，因为维护者的验证、分流和发布速率保持平稳。这与我从OSS维护者的角度的看法不幸一致：问题不在于前沿模型、开放权重模型或程序分析“胜出”。问题是如何协调它们，使得稀缺的验证、优先级和发布能力能够用于持久的修复，而不是机械的搜索和报告草拟。一个中央防御者的机会是技术债务的缓解：基于语义、工具验证、模型辅助的工作流程，帮助维护者在保存成为明天被利用的漏洞之前发现、验证、优先级和修复与安全相关的缺陷。 -- 解密神话还是颠覆漏洞经济？Pesoli等，2026年 那维护者的能力为什么保持平稳？显然，不接触像Mythos这样的前沿代理是一个原因，但没有引起回归的安全补丁的工程本质上也意味着更多的工作。 3 那我们到底该如何做？ 我们显然需要迅速适应。我认为当前的手动分流流程不应该消失，但是自从Fable发布以来，我看到了一波不可持续的活动。我们刚刚开始了解有多少