如今，仅仅关于错误的谣言就足以找到漏洞

我今天发布了 OCaml 的 cohttp 6.3.0 的安全修复程序，修复了路径遍历问题。补丁本身很简单，在正常情况下，安全程序是私下修复它，通知受影响的用户，然后发布公共咨询。不过这一次，我注意到在打开 PR 来解决问题几分钟后，我的实时网络服务器日志中就出现了具有确切错误模式的探测。更糟糕的是，我发现我可以使用自己的代理来找到该漏洞，只需大致了解它的内容，因此可以在公共补丁可用之前就利用它！鉴于安全问题的谣言似乎足以为攻击者提供足够的信息来寻找新的漏洞，我们需要改变处理开源安全响应的方式。 1 有关 bug 的谣言是所有新的代理漏洞利用系统都需要的这份特殊报告上周通过 Jane Street 在 Slack 频道上私下发布，并且是通过 Claude Fable 发现的。这大大压缩了所有时间线... 1.1 现代安全报告的时间线 在详细检查补丁之前，我将自己的 Claude 指向受影响的代码，看看还潜伏着什么（要求它调查路径规范化问题）。由于我无法访问 Glasswing，Fable 因安全阻止而令人沮丧地彻底拒绝，但 DeepSeek V4 Pro 答应了我的要求，并独立地发现了几个相关问题。我的代理还轻松地创建了一个漏洞，可以在一分钟内探测本地实时服务器。在与错误报告者就可能的修复进行了一番反复讨论之后，我悄悄地公开打开了 cohttp#1145，以吸引更多人关注它。这通常需要几天的时间，一两周内发布是合理的。在大约十分钟内（！），该网站就对百分比编码的遍历序列进行了探测，这表明自动观察者正在密切关注公共存储库。如果我只花了一分钟在本地创建自己的漏洞利用程序，那么十分钟实际上对于自动攻击窗口的启动来说似乎相当长！正在监控软件包存储库的坚定攻击者可以在几秒钟内轻松利用它们。 1.2 安全禁运不再有效 传统的安全流程涉及禁止错误，并假设详细信息的保密性可以保护用户。然而，今天的代理所需要的只是一个广泛的搜索方向，并且它可以进行自己的研究。方等人。发现，当给出 CVE 描述时，他们的 GPT-4 代理利用了 15 个漏洞基准的 87%，而没有描述，则仅利用了 7%。两年过去了，平均利用时间为-7 天。换句话说，利用现在先于补丁！同样的指标在 2018-19 年大约为 63 天，并在 2024 年跨越了零。这些天快速搜索发现了许多其他类似的案例……marimo 的 CVE-2026-39987 在 9 小时内从咨询到首次利用尝试，即使不存在公开的概念验证。 Langflow 的 CVE-2026-33017 花费了 20 个小时。我们似乎已经跨越了自动化漏洞利用生成的障碍... 2026 年 LLM 漏洞利用的状态（来源：Vulncheck） 2 现在的 bugonomics 是否针对 OSS 维护者？在我看来，我们的安全流程需要进行一些逆转，因为只有一个人搜索问题类（这可能是邮件列表问题、孤立分支中的奇怪提交或上下文泄漏）就足以提醒其他人的代理并让他们获取漏洞利用代码。这太疯狂了。 2026 年 5 月的一篇论文创造了“错误经济学”一词，并认为瓶颈已转移到“防御者补救吞吐量”。 LLM 正在愉快地产生漏洞，但我们防御它们的能力并不一定会提高，因为维护者验证、分类和发布率保持不变。不幸的是，这与我的 OSS 维护者主席的观点相符：问题不在于前沿模型、开放权重模型或程序分析是否“获胜”。问题是如何编排它们，以便将稀缺的验证、优先级和发布能力用于持久修复，而不是机械搜索和报告起草。中央防御者的机会是技术债务补救：基于语义、工具验证、模型辅助的工作流程，帮助维护人员在与安全相关的缺陷成为明天被利用的漏洞之前发现、验证、确定优先级并修复它们。 ——揭开神话的神秘面纱还是破坏错误经济学？ , Pesoli et al, 2026 为什么维护者能力保持不变？好吧，无法访问像 Mythos 这样的前沿代理是一个明显的问题，但设计一个不会导致任何回归的安全补丁从根本上来说只是更多的工作。 3 那么我们到底能做些什么呢？我们显然需要相当快地适应。我认为当前的手动分类流程不应该消失，但自从《神鬼寓言》问世以来，我已经看到了不可持续的活动激增。我们才刚刚开始了解有多少 i