一个用真账本算分的新基准
本周，一个名为 CVE-Bench 的评估基准在开发者社区里慢慢传开。和那些已经被刷烂的 SWE-Bench、HumanEval 不同，它要回答的问题很具体：给一个 AI Agent 一份真实存在过的 CVE 漏洞报告，外加这个项目对应版本的源代码，它能不能写出一个等价于人类维护者当年提交的修复补丁？
这件事看起来不大，但角度很刁。过去一年里，关于 "AI 能不能做安全" 的讨论几乎全都集中在攻击侧——从 Google Project Zero 的 Naptime/Big Sleep，到 ICML 2025 上那个同名的 CVE-Bench（注意，那是另一个，专门测 Agent 利用 Web 漏洞能力的基准，state-of-the-art Agent 框架成功率只有 13%）——而防御侧、特别是 "修补丁" 这件最朴素的工作，反而一直缺一把像样的尺子。
本周这个 CVE-Bench 补上了这一刀。
它和那个 "攻击版" CVE-Bench 完全是两回事
这里必须先把名字这个坑填了。
搜索 "CVE-Bench" 你大概率会先撞上 arXiv 2503.17332 那篇——那是 UIUC 团队在 ICML 2025 投的工作，做的是 Agent 攻击 Web 应用 的沙箱评测：内置一批关键级 CVE 对应的容器化 Web 应用，让 Agent 在隔离环境里尝试触发漏洞，自动判定是否成功。那篇的结论挺扎眼的：当时最强的 Agent 框架，能打下来的也只有 13% 左右。
本周这个新 CVE-Bench（作者 Giovanni Gatti，主页托管在 GitHub Pages 上）做的是 完全反向 的事：
- 输入：CVE 描述、受影响版本的源码仓库快照、（可选的）漏洞触发用例
- 任务：Agent 自主分析、定位、生成补丁
- 评测：用项目维护者当年实际合并的修复 commit 作为 ground truth，再加上一组针对该漏洞的 PoC 测试用例，验证 Agent 的补丁是否真的堵住了洞、又没把别的地方改坏
一个攻、一个防，名字撞车纯属巧合，但放在一起看反而成了完整闭环。如果一个 Agent 在攻击版 CVE-Bench 上能打下 X% 的漏洞，在修补版 CVE-Bench 上能修好 Y%，那么 (X-Y) 大致就是这个模型当前对人类安全工程师构成的净风险溢出。 这个差值，比单看任何一个数字都有意义。
数据集是怎么挑的
这是新基准最值得说的部分。
做漏洞修复评测最容易翻车的地方是 数据泄漏：CVE 是公开的，补丁也是公开的，模型预训练时几乎一定见过。如果你拿 2019 年的 Log4Shell 去测 GPT-5，它"修"出来的代码大概率是从训练语料里背出来的，根本不算能力。
CVE-Bench 的处理思路有几条值得注意：
- 优先选 cutoff 之后的 CVE。对每个被测模型，只保留发布日期晚于其训练截止时间的漏洞。这意味着同一份榜单上，不同模型实际跑的子集是不一样的——评测维度从单一分数变成了 "在你没见过的那部分上你能修对多少"。
- 强制 PoC 验证。光看 diff 和 ground truth 像不像没用，因为同一个洞可以有无数种合法修法。每个样本都附带一组在打补丁前能稳定触发漏洞、打补丁后失效的测试。Agent 改完，自动跑 PoC：原来红的得变绿，原来绿的不能变红。
- 覆盖多语言、多项目类型。当前公开的样本里能看到 Python、JavaScript/Node、PHP、Java、Go 的混合，从 Web 框架到解析器到 CLI 工具都有，没有偏向某一类"模型擅长"的代码风格。
- 保留完整仓库上下文。不是只给一个文件、不是只给函数 snippet，而是给完整的项目结构。Agent 得自己用工具去 grep、去读、去翻 git history。这一点直接决定了它测的是 Agent 而不是单轮补全模型。
为什么是现在
时间点其实非常微妙。
过去半年，几家头部实验室在安全 Agent 上的进展都开始 "出真章"：Anthropic 把 Claude 的 Computer Use 接到了 CTF 流水线、Google DeepMind 的 Big Sleep 公开宣称在主线开源项目里发现了多个真实 0day、OpenAI 则在 GPT-5 系列的发布材料里专门列了 "autonomous vulnerability discovery" 的内部评测分数。问题是——所有这些数字都是各家自己出题、自己阅卷。
横向可比的、第三方维护的、不可作弊的基准，市场上几乎是空白。CVE-Bench 这次抢到了一个不错的位置：它不试图回答 "Agent 能不能成为 AI 红队"，只问一个非常工程化的问题——"它能不能替你处理 GitHub Security Advisory 收件箱里那些 Dependabot 升不动、需要你自己手写 patch 的 CVE？"
这个问题对企业开发者来说太具体了。任何一个稍微有点规模的产品团队，都被这事折磨过：一个三年没人维护的内部依赖，突然爆个 CVE，原作者早跑了，你得自己 fork 出来打补丁。这种活，单价不高、重复性强、责任不小，是 Agent 的绝佳着陆点。
早期跑分透露了什么
作者放出了第一批跑分（仍在持续更新中），几个观察：
- 修复成功率的天花板远高于攻击成功率。在初步公开的子集上，主流前沿模型（Claude、GPT、Gemini 的最新版本）作为 Agent 跑出来的 patch 通过率，明显比 ICML 那版 CVE-Bench 的 13% 高出一截。这符合直觉：修一个已知问题，本质上是一个有明确目标、有验证信号的任务；而"自主找洞"是开放搜索。
- 失败模式高度集中。大量失败不在于改不对，而在于改得太多——Agent 倾向于顺手 "清理" 一些它看着不顺眼的代码，导致 PoC 之外的回归测试挂掉。这其实是个老问题了，SWE-Bench 上也存在，但放在安全场景里更刺眼：一个引入了行为变更的 "修复 patch"，在生产环境就是一个 P0 事故源。
- 跨语言差距比想象中大。同一个模型在 Python 项目上能跑到 50%+，到了 PHP 老项目（典型场景：WordPress 插件、老版 Laravel）直接腰斩。和训练语料分布完全对得上，但也提醒大家：拿"平均分"评估 Agent 安全能力是危险的，按技术栈分桶看更有意义。
几个值得吐槽的地方
捧完了说点不客气的。
第一，样本量还是太小。 目前公开样本数量在百级别，对于一个想成为 "安全届 SWE-Bench" 的基准来说，不够。SWE-Bench Verified 也才 500 题就被认为偏少了。漏洞类型的长尾极长，从 SQL 注入到原型链污染到反序列化 RCE，每一类都需要足够样本才能让分数稳定。
第二，PoC 不一定捕捉到漏洞的全部攻击面。 一个 SSRF 漏洞，作者写的 PoC 可能只覆盖了 HTTP gopher://，而 Agent 改完只挡了 HTTP，gopher 还能打。但 PoC 通过了，分数就给了。这种 "假阳性修复" 在真实安全工程里是大忌，基准本身需要更激进的多 payload 验证策略。
第三，缺少"诱饵"题。 一个成熟的修复基准应该混入一些 "看起来像漏洞但其实不是" 的题目，测 Agent 会不会瞎改。现在的版本里所有题目都是确凿的 CVE，Agent 默认 "一定有问题需要修"——这和真实工作流（先得判断报告是不是误报）有差距。
这些都是可以演进的方向。作者在仓库里也明确写了 roadmap，欢迎社区贡献新样本。
对开发者意味着什么
短期看，CVE-Bench 不会直接改变你的工作流。但有几件事值得留意：
- 选模型多了一个真实参考。 下次你要在内部 SRE 工具链里塞一个 "自动 CVE 处理 Agent"，至少有个非厂商口径的数字可以横向对比。Claude、GPT、Gemini、DeepSeek、Qwen 都会陆续被跑。
- "Agent 工程" 的细节会被放大。 同样的底层模型，配上不同的工具集（是否给 git blame、是否给历史 PR、是否允许跑测试）跑分能差出十几个百分点。基准的存在，会逼着大家把这些工程选择 reverse-engineer 出来。
- 多模型对比成为日常需求。 现实是，没有任何一个模型在所有语言、所有漏洞类型上都最强。修 Python 的 deserialization 漏洞可能 Claude 最稳，修 Java 的 XXE 可能 Gemini 更准，处理大量历史代码翻阅可能要靠 GPT 的长上下文——这是真实评测数据反复显示的模式。对国内团队来说，这也是为什么像 OpenAI Hub 这种聚合接入的方案最近用的人多了起来：同一个 Key 同时调 GPT、Claude、Gemini、DeepSeek，按任务路由比绑死一家更划算，也省去了海外多个账号的麻烦。
写在后面
安全这件事，永远是 "攻击者一点突破，防御者全面失守"。CVE-Bench（这个修补版）出现的意义，是终于有人开始系统地、可复现地衡量 AI 在防御侧的真实斤两，而不是只盯着各种 "AI 黑客" 的耸动 demo。
做 AI 安全评测的人都清楚一件事：有基准就有进步，没基准全是吹。SWE-Bench 用了两年把 "Agent 改代码" 从 2% 推到了 70%+，CVE-Bench 现在站在的，可能就是同样故事的起点。
值得继续盯。
参考来源
- arXiv 2503.17332 - CVE-Bench (攻击版) 论文页 - UIUC 团队提出的同名基准，注意区分，这一篇做的是 Agent 利用 Web 漏洞的能力评测