找到漏洞的是脚手架，不是模型

一览

2026 年的两个数据点，一个来自商业界、一个来自学术界，指向同一个方向。

curl 那边究竟发生了什么

curl 8.22.0 于 2026 年 9 月 2 日发布，带着九份安全公告。其中六份署的是同一位报告人——AISLE 的 Stanislav Fort——这些发现提交于八月下旬的四天之内：OpenSSL provider 路径上的一处 use-after-free、一处 pinning 绕过、一个原生 CA 存储的连接复用问题、一处借助制表符实现的 secure-cookie 属性绕过、一次 wolfSSL CA 缓存回调覆盖，以及一个域范围的公共后缀 cookie 问题。六个全部评为 Low。

这并不是第一批。在六月的 curl 8.21.0 里，十八个 CVE——单次 curl 发布的纪录——中也有六个署着 AISLE，其中包括 CVE-2026-8932：它最早随 2001 年 3 月 22 日发布的 curl 7.7 出厂，是该项目历史上最老的安全问题。二十五年的模糊测试、静态分析、付费审计和一个漏洞赏金计划，都从它旁边走了过去。

AISLE 关于「Codex 与 Mythos 在同一窗口里一无所获」的说法出自厂商自己，读的时候就该按这个分量来读。但不依赖于信任厂商的那部分，是这件产物的形状：一家自己并无前沿模型的小公司，把一个专门打造的分析器对准一个人人都已经看过的代码库，然后拿到了受理。

那个把两个变量分开的基准

当一家厂商赢过前沿模型时，有用的问题是「哪个变量被挪动了」。HoF-Bench 就是为回答它而建的。这个基准取了八个仓库里 95 个公开的、由 AI 发现的 CVE，把每一个钉在其有漏洞的提交上，交给分析器源码与目标文件范围——但不给 CVE 编号、不给描述、不给修复、也不给预期的成因机制。随后由一位对检测器盲的裁判来判定：只有当一项发现指出了相同的代码路径、相同的根因、相同的触发条件和相同的影响时，才算数。这道门槛，比「它有没有提到缓冲区」严苛得多。

结果

在这套协议下，一个刻意做得极简的、基于 LLM 的分析器重新找回了 95 个中的至多 65 个——约 68%。十个检测骨干模型是五个开放权重模型（总参数 21B–284B，激活 3B–13B）与五个专有的小型或 flash 档模型。全研究中的检测环节没有任何前沿模型参与。所有检测器都跑在同一套固定脚手架里：四轮重复、一个可选的上下文生成阶段，以及一个可重放的多轮分诊阶段，合计 7,600 条「模型-CVE」轮次记录。

这意味着什么

如果三分之二的真实、且已被找到过的漏洞，能被一个激活参数只有 3B–13B 的模型在一个像样的外壳里重复四遍就找回来，那么对那些 bug 而言，检测能力就不是那个约束条件。搜索结构才是。这是一个通常只能定性表述的论点的具体版本：每个智能体分数都是模型与它所在那层外壳的联合得分，而上标题的只有其中一个。

也请留意漏掉的部分集中在哪里。HoF-Bench 里的难度被编程语言强烈地结构化，而所有模型都漏掉的那些 CVE 扎堆在 C 语言的基础设施代码里——不巧，那正是 curl 所属的品类。剩下那三分之一不是均匀分布的噪声；它是一类「廉价轮次重复多少遍也够不着」的特定 bug。

召回正在变便宜。精确率才是没人在卖的那个

接下来是那个该改变你计划的数字。AISLE 称自己提交了 29 份报告，六份被接受。那大约是五分之一的受理率——而且是在一次跑得不错的运行里、由一位专家、面向一个维护者严谨得出奇的项目取得的——而另外那 23 份，每一份都消耗了某个人的注意力。

curl 在 2026 年 1 月关停它的 HackerOne 漏洞赏金，正是为了这件事：一波自信、详尽、却纯属编造的报告涌了进来，来自那些为了赏金把 LLM 对准代码库的人。后来在两次发布里接受了十二个 AISLE CVE 的，正是那个早已把前门关上的项目——因为在有人真的读完报告之前，一个好分析器与一台废话生成器之间的差别是看不见的。

严重度是第三个数字，也是安静的那一个。九月那六项发现全部评为 Low。这不是批评——curl 里一个真实的 Low 就是一个真实的 bug——但它确实意味着这一批的价值要用「加固」来计量，而不是用「避免了事故」来计量，而加固要和其他一切争抢同一批维护者工时。一个每产出一项被接受的结果就附带二十个 Low 的自动发现器，并不显然是一份礼物。

如果你要买或者要造一个，该换个什么做法

采购时的直觉是问这个安全产品用的是哪个模型。就这批证据而言，那是你能问出的信息量最小的问题。

• 去问脚手架，问细一点。跑几轮，轮与轮之间有什么变化。有没有上下文生成阶段、它吃的是什么。分诊怎么做、跑几轮。在人看到之前，跨轮的发现有没有去重。在唯一一次有对照的比较里，被挪动了数字的正是这些部分。
• 把受理当作指标，而不是把发现数当指标。「每个仓库找到几个」是个虚荣数字。「每个维护者分诊工时换来几项被接受的发现」才是决定这个工具是否净为正的数字，而且在你自己的待办上，一周就能测出来。
• 先给分诊列预算，再给令牌列预算。一个便宜但受理率糟糕的检测器，会把它的成本转嫁给你本想帮的那些人；而与推理不同，这项成本不会每个季度往下掉。
• 在你自己的语言、你自己的代码上做评测。那条关于 C 基础设施代码的结论说明，难度是被「你写的是什么」结构化的，而不是被排行榜的平均数结构化的。把你自己历史上的十个 CVE 钉在各自有漏洞的提交上，然后让工具盲跑——这是两天的工作量，胜过任何厂商基准。
• 把「找出来」和「修好」分开。这是两种能力，失败代价也不同；后一半见漏洞修复智能体。

越过安全领域仍然成立的那部分

这里的具体主张是关于漏洞发现的。一般性的那个，则关于任何「核验一个答案比产出它更便宜」的任务。检测是最纯粹的例子：一个候选发现只要一轮，确认它只要一次分诊——于是重复是划算的，而用便宜模型重复，比用昂贵模型试一次更划算。

这是生成-核验落差站在你这一边的情形，而它把通常的建议翻了过来。核验便宜的地方，买轮次。核验昂贵的地方——多数智能体工作都是如此，因为检查输出意味着把活儿再干一遍——买能力。多数团队对这两种情形用同一条规则，而 curl 这个结果提醒我们：把分类朝「昂贵模型」那一侧弄错，代价是多少。

延伸阅读

本站相关：

• 智能体外壳——为何每个智能体基准分都在给两样东西打分，却只点名其中一个。
• 生成-核验落差——重复何时胜过能力，何时不。
• 智能体搜索策略——把轮次、广度与重采样当作设计选择。
• 漏洞修复智能体——问题的修复那一半。
• 基准污染——为何「钉在有漏洞的提交上」很要紧。

来源：

• curl 安全公告——CVE 署名与严重度评级。
• HoF-Bench: Rediscovering Real AI-Discovered CVEs Without Frontier Models（arXiv 2607.27030）。
• AISLE：curl 中六个新 CVE，含史上最老的一个问题。
• curl 8.22.0 发布说明。