CVE-Bench：在真实世界漏洞补丁上测试 LLM 智能体

背景

2026 年初，Anthropic 宣称其最新模型 Mythos 在发现安全漏洞方面优于人类专家。然而，现实情况是安全漏洞的数量仍在持续攀升。这一矛盾促使作者思考：现有的模型在修复漏洞方面的实际表现究竟如何？

虽然 Poolside 推出的 Laguna 模型今年问世，但作者认为现有的默认基准测试（如 SWE-Bench）主要测试通用代码能力，缺乏针对安全领域的尖锐挑战。为了填补这一空白，作者创建了 CVE-Bench，这是一个专门针对真实世界安全漏洞的基准测试。该测试包含 20 个真实 CVE（通用漏洞披露）案例，评估 5 个模型，并设置三种不同的提示（prompt）条件。每个智能体（Agent）都在沙盒容器中运行，并根据维护者提供的安全测试（经过适当调整）进行评分。

核心内容

安全漏洞的结构与数据源

当安全研究人员发现漏洞时，通常遵循“负责任披露”流程：私下联系维护者，提供包含漏洞结构化描述的建议书（advisory），并在公开前协调修复。一旦修复发布，CVE 标识符会被分配，建议书也会公开，以便用户更新受影响的依赖项。

GitHub Advisory Database (GHSA) 是开源软件漏洞编目的主要努力方向，它允许将 CVE 和建议书链接到具体的仓库、维护者和修复版本。此外，CVE 使用通用弱点枚举（CWE）代码对弱点进行分类（例如 CWE-22 为路径遍历，CWE-79 为 XSS）。

对于构建基准测试而言，GHSA 的最大价值在于：维护者越来越多地直接在工单中链接其修复代码（如 commit SHA 或 Pull Request）。如果链接不可用，则可以通过查阅发行说明或第一个修复版本的 git 历史来获取“地面真值”（ground truth）。

任务筛选与构建

CVE-Bench 针对广泛的 CWE 问题（15 个类别），CVSS 评分从 2.1 到 9.8 不等，涵盖了一系列真实的 Python 项目（如 Pillow, GitPython, yt-dlp, urllib3，共 18 个项目）。

为了确保基准测试的可操作性，作者过滤掉了以下类型的建议：

• 单体仓库（Monorepos）：如 LangChain、Kubernetes 或 Apache 项目，这些项目下载量达数百 MB，且构建/测试隔离复杂。
• 非 Python 语言：涉及 Rust、C、C++ 或其他编译语言的修复，因为智能体需要编译器工具链且构建周期缓慢。
• 重大 API 重构：如果提交的修复引入了显著的 API 重构，要求智能体引入完全相同的领域变更，这类任务也被排除。

对于每个选定的项目，CVE-Bench 提供：

1. 易受攻击和已修复的 git SHA。
2. 一个初始化 Docker 容器内易受攻击仓库的设置脚本。
3. 一个手动策划的 test_security.py，其中包含至少一个能暴露安全漏洞但在修复代码中通过的测试。

智能体的目标是在无法访问验证脚本的情况下，根据任务描述修复报告的安全漏洞。

测试用例的自动化生成

作者最初计划直接使用维护者提供的新测试作为标准解决方案，但发现许多漏洞修复并未附带适当的测试。由于缺乏测试套件，许多优秀的漏洞案例无法被利用。

经过尝试手动修补测试（这是一项繁琐的工作）后，作者发现最简单有效的替代方案是：向 Claude Sonnet 提供建议书、原始代码和安全补丁，并要求其创建独立的测试。这种方法效果出奇地好且易于验证：只需检查测试套件在易受攻击的提交中失败，而在修复的提交中通过即可。

为了最小化数据集污染的风险，大多数选定的 CVE 都是近期的（2026 年初，其中 16 个在 2026 年 3 月之后发布，最旧的例子来自 2025 年 11 月）。尽管这并不意味着修复是最近的（CVE 公开时间通常晚于修复发布时间），模型可能已经见过特定的代码提交，但“建议书 -> 修复”的链接出现在训练数据中的可能性较低。

提示工程与任务设计

作者设计了三种不同的提示条件，以测试模型的不同能力：

1. Advisory（建议书提示）：这是最丰富、最真实的条件。提示内容为 GHSA 建议书，去除了对修复提交或补丁版本的任何引用。它通常提供完整图景：漏洞类别、根本原因、受影响的代码路径、攻击场景，有时还包括概念验证（PoC）。
2. Diagnose（诊断提示）：完全剥离位置信息。智能体仅获得漏洞的行为描述（攻击者能做什么以及如何做），没有文件路径、函数名或代码。智能体必须搜索代码库，假设漏洞所在位置并修复它。这测试模型从症状推导原因的能力。
3. Locate（定位提示）：反转上述逻辑，提供精确的位置（文件和函数），但不描述错误所在。智能体可以冷读代码，必须独立判断哪里出了问题以及如何修复。

这种设计旨在揭示模型为何表现更好，而不仅仅是谁表现更好。Advisory 性能天生存在噪音（有些建议书近乎处方式，有些则很简略）。Diagnose 是最难走捷径的，因为缺乏锚点和位置；Locate 最接近安全研究人员实际做的工作——阅读从未被告知有问题的代码并独立识别危险。

关键要点

• 基准测试的针对性：CVE-Bench 专门针对真实世界的安全漏洞，区别于测试通用代码能力的 SWE-Bench，旨在解决安全领域“高 stakes”（高风险）的问题。
• 数据筛选标准：为了保持基准测试的可操作性，排除了单体仓库、非 Python 语言项目以及涉及重大 API 重构的复杂案例，聚焦于 18 个真实的 Python 项目。
• 自动化测试生成：针对许多漏洞缺乏配套测试的问题，作者利用 Claude Sonnet 根据原始代码和补丁自动生成独立的验证测试，解决了数据标注难题。
• 防污染策略：主要选用 2026 年初发布的 CVE，虽然不能完全排除模型见过代码提交，但大幅降低了“建议书到修复”这一特定关联数据泄露的风险。
• 多维度的评估框架：
  • Advisory：测试模型在真实世界模糊信息下的修复能力。
  • Diagnose：测试模型从行为描述推导代码位置的能力（最难走捷径）。
  • Locate：测试模型独立识别代码中潜在危险的能力（最接近人类专家工作流）。
• 能力剖面分析：通过对比三种条件下的表现，可以区分模型是真正理解安全逻辑，还是仅仅在遵循指令或进行模式匹配。

意义与影响

CVE-Bench 的提出标志着 AI 安全评估从“通用代码生成”向“特定领域安全推理”的深入。通过引入 Diagnose 和 Locate 两种提示条件，该基准测试不仅衡量模型“能否修复”，更揭示了模型“如何思考”。

如果一个模型在 Advisory 上表现良好但在 Diagnose 上大幅下滑，说明它可能过度依赖建议书的描述而非真正的漏洞推理；反之，如果在 Locate 上得分高，则表明模型具备独立识别危险代码的能力。这种细粒度的评估有助于社区更准确地判断当前 LLM 智能体在应对真实世界安全威胁时的可靠性，从而在漏洞被利用之前协助社区修复问题，提升开源生态的整体安全性。