CVE-bench

CVE-bench是一个用于评估AI代理修复真实开源软件中安全漏洞能力的严格基准测试数据集。它采用SWE-bench方法应用于安全领域：应用补丁→安全测试。每个实例都是一个来自公共开源仓库的真实CVE，并包含一个一致性防火墙，确保求解器永远不会看到黄金补丁或黄金安全测试。数据集包含5个已验证的实例，均来自PyPI（Python），涵盖算法混淆、拒绝服务、数据泄露等安全漏洞。CVE-bench is a rigorous benchmark dataset for evaluating the capability of AI Agents to repair security vulnerabilities in real-world open-source software. It applies the SWE-bench methodology to the security domain, following the workflow of patch application → security testing. Each instance is a real CVE sourced from public open-source repositories, and includes a consistency firewall that ensures solvers will never have access to the golden patch or golden security tests. The dataset contains 5 validated instances, all sourced from PyPI (Python), covering security vulnerabilities such as algorithm obfuscation, Denial of Service (DoS), data leakage, and others.

原始信息汇总

数据集概述

CVE-bench 是一个面向 AI 代理的、评估其修复开源软件中真实安全漏洞能力的基准测试。它采用类似 SWE-bench 的方法论：应用补丁后进行安全测试。

数据集规模与内容

• 当前规模：包含 5 个经过验证的实例，全部来自 PyPI（Python 生态系统）。
• 实例列表：
  • CVE-2022-29217 (pyjwt)：JWT 密钥处理中的算法混淆漏洞
  • CVE-2023-44271 (Pillow)：因无界字符串长度导致的拒绝服务漏洞
  • CVE-2023-45803 (urllib3)：HTTP 重定向泄露包含敏感数据的请求体
  • CVE-2023-32681 (requests)：HTTPS 重定向时代理凭证泄露
  • CVE-2016-2512 (Django)：恶意重定向漏洞（CWE-601）
• 扩展路径：构建流程完整，可通过 OSV.dev 拉取候选 CVE，经 §42 验证门后合并入库。在一个10分片GCP验证活动中，扫描了约50个PyPI包，最终获得1个新通过验证的实例（CVE-2016-2512），验证通过率约2%。

数据实例结构

每个 CVE-bench 实例包含以下字段：

• instance_id：CVE 标识符
• repo：上游 GitHub 仓库地址
• base_commit：安全修复提交之前的那个提交
• fix_commit：修复 CVE 的提交（仅用于提取差异，不提供给求解器）
• problem_statement：漏洞的公开公告描述（求解器获得的唯一信息）
• patch：修复提交中的源代码变更（对求解器保密，仅用于验证）
• test_patch：修复提交中添加的回归测试，在修复前失败，修复后通过
• FAIL_TO_PASS：应用代理补丁后必须通过的 pytest 测试 ID
• env_hint：每个仓库的环境设置元数据（apt 包、pip 依赖）

设计原理与合规防火墙

• 核心保证：在评分过程中，代理的补丁是唯一被应用的源码侧变更。黄金补丁和黄金安全测试绝不会展示给求解器。
• 求解阶段：代理读取公告和 base_commit 时的仓库源码，生成 model_patch。
• 评分阶段：测试框架应用 base_commit + model_patch + test_patch，然后运行 FAIL_TO_PASS 测试。
• 验证阶段：黄金补丁仅在 --validate 时使用，确认黄金修复本身能通过测试，评分时绝不使用。
• 防止数据污染：代理无法通过记忆修复方式来作弊。

评分规则

一个提交成功解决一个实例必须满足：

1. model_patch 能够无冲突地应用到 base_commit。
2. 安全 test_patch 能够在其基础上应用。
3. 所有 FAIL_TO_PASS 测试执行并通过。

如果测试无法运行（收集错误、依赖缺失），该实例被标记为"未运行"，不计入通过或失败。

环境构建与规模挑战

• 瓶颈：为每个实例构建可复现的 Docker 环境是最大挑战。需要为每个仓库在特定历史版本下安装正确的 Python、系统库和测试依赖。
• 解决方案：
  1. SWE-bench 配方复用：对于 SWE-bench 支持过的仓库（如 django, requests, pillow 等），复用其已知有效的环境配方。
  2. 时代对齐环境构建：为其他仓库选择与 CVE 日期相近的 Python 版本，安装其时代固定的依赖，并进行配置兼容性适配。
• 效果：新构建器将之前被环境墙阻挡的候选实例验证率从 0% 提升至约 35%（23个被挡实例中有8个通过验证）。

数据集来源与合法性

• CVE 数据：来自公开的 OSV.dev 数据库。
• 仓库源码：来自公开的 GitHub 仓库（只读克隆）。
• 差异：提取自公开的修复提交，仅存储变更的差异，不存储完整源码。
• 许可证：CVE-bench 框架采用 MIT 许可证。上游仓库代码遵循各自许可证。

搜集汇总

数据集介绍

构建方式

CVE-bench的构建严格遵循SWE-bench的方法论，即“应用补丁→安全测试”的范式。每个实例均源自公开开源仓库中的真实CVE，通过OSV.dev获取漏洞信息，利用GitHub API提取修复提交的差异，并拆分为源代码补丁（patch）与安全回归测试（test_patch）。构建过程中实施§42判别门控：仅当基提交结合测试补丁时测试失败（漏洞存在），而基提交结合修复补丁与测试补丁时测试通过（修复有效），方被纳入数据集。该数据集的构建还特别考虑了时代锁定的Docker环境构建，针对每个仓库复用或定制环境配方，以解决因环境不兼容导致的测试无法运行问题，确保每个实例均具备真实的判别能力。

特点

CVE-bench的核心特点在于其严格的合规防火墙机制，确保求解器在解决过程中从未接触黄金补丁或黄金安全测试，从根本上防止基准污染。数据集仅包含5个经过严格验证的实例，全部来自Python生态的知名项目（如pyjwt、Pillow、urllib3、requests、Django），涵盖JWT算法混淆、拒绝服务、敏感数据泄露、凭证泄露与恶意重定向等多种真实安全漏洞。虽然数据集规模较小，但每个实例均经过§42判别门控的严格筛选，确保具有真实的漏洞修复难度。此外，该基准诚实报告评估结果，拒绝因环境失败而错误计分，所有“无法运行”的实例均被排除，而非视为通过或失败。

使用方法

使用CVE-bench评估AI代理时，需先确保安装Docker与Node.js≥20环境。求解器以公开漏洞描述（problem_statement）为唯一输入，在基提交代码库上生成模型补丁（model_patch），并输出为predictions.jsonl文件，每行包含实例ID与符合git-apply格式的统一差异。通过运行npm run grade命令，评估框架将依次应用基提交、模型补丁与安全测试补丁，并执行FAIL_TO_PASS指定的pytest测试，以判定实例是否被正确修复。求解结果可通过npm run leaderboard生成排行榜，展示各求解器的修复率与每实例成本，同时支持通过Pull Request提交新的求解方案，CI系统会自动重新评分以确保结果的可信度。

背景与挑战

背景概述

CVE-bench是一个旨在评估人工智能代理修复真实开源软件中安全漏洞能力的基准测试，创建于2026年，由ruvnet团队开发。其核心研究问题聚焦于如何在严格保密的条件下衡量智能体对已知漏洞（CVE）的修复效能，借鉴了SWE-bench的方法论，通过“应用补丁→安全测试”的流程来验证修复是否成功。该数据集包含5个经过严格筛选的实例，全部来自PyPI生态系统，涵盖JWT密钥混淆、拒绝服务、HTTP重定向泄露等典型安全威胁。CVE-bench的独特价值在于其引入的一致性防火墙机制，确保评估过程中求解器无法接触金标准补丁或安全测试，从而杜绝基准污染，为安全自动化修复领域提供了首个具备严谨验证流程的评估框架，对推动AI驱动的漏洞修复研究具有里程碑意义。

当前挑战

CVE-bench面临的首要挑战是领域问题的复杂性：真实世界的安全漏洞往往涉及跨语言、跨组件依赖和隐含的上下文知识，而当前AI代理在理解漏洞描述与生成精确补丁之间仍存在巨大鸿沟，尤其在处理算法混淆（如CVE-2022-29217）和敏感数据泄露（如CVE-2023-45803）这类需要深层语义推理的漏洞时，修复成功率极低。构建过程中最大挑战是每个实例的Docker环境搭建——从克隆历史仓库、安装遗留依赖到配置与旧版Python兼容的测试框架，任何一个环节的失败都会导致候选实例被剔除；最初使用通用Python镜像构建时，约23个候选实例中仅有0个通过验证，而改进后的时代锁定环境构建策略虽将验证率提升至35%，但依然面临大量非判别性失败的实例。此外，数据集规模仅有5个实例，因为从开源安全数据库OSV.dev提取的数百个候选经过严格筛选后，能通过双重验证（基线上安全测试失败、金补丁后测试通过）的实例凤毛麟角，这种高质量但小规模的状态限制了模型的泛化评估能力。

常用场景

经典使用场景

在软件安全领域，CVE-bench 数据集被广泛用于评估和比较人工智能代理修复真实世界中开源软件安全漏洞的能力。该数据集遵循 SWE-bench 方法论，为每个实例提供了包含公共漏洞描述、基准提交和修复提交等信息的结构化数据。研究者可以基于此构建自动化漏洞修复系统，通过对模型生成的补丁进行严格的合规性测试来检验其有效性。其经典使用流程包括：从公开的 CVE 数据库中获取漏洞信息，让代理仅依据公共安全公告分析源代码并生成补丁，随后在隔离环境中验证补丁能否通过安全回归测试。这种设计确保了评估的公平性和可信度。

衍生相关工作

CVE-bench 数据集的推出推动了多项衍生工作的进展。研究者基于其架构设计了多种合规的自动化求解器，如参考级联求解器利用廉价模型进行初步覆盖、昂贵模型进行精调，展示了不同成本下的修复性能。此外，围绕环境构建瓶颈，出现了改进型环境配方复用策略和时代锁定构建器，显著提升了历史版本代码的测试通过率，使得更多候选实例能够通过第42条区分门验证。该数据集还催生了新的领导者榜单设计，通过可视化解析率与每实例成本的二维关系，为社区提供了更直观的模型比较方式。这些相关工作进一步拓展了安全基准的实用性和影响力，推动了自动化漏洞修复技术的成熟。

数据集最近研究

最新研究方向

CVE-bench作为首个严格遵循SWE-bench方法论的安全基准测试，开创性地将AI智能体修复真实软件漏洞的能力评估引入标准化范式。该基准通过创新的“一致性防火墙”（Conformance Firewall）设计，彻底杜绝了评测作弊风险，仅向求解器暴露公共漏洞描述，而将黄金补丁与安全测试完全隔离。当前数据集中已验证的5个实例（涵盖JWT算法混淆、Pillow拒绝服务、urllib3敏感数据泄露等典型安全威胁）虽然规模尚小，但标志着AI安全修复评测从简单合成漏洞向真实CVE漏洞的重大突破。值得关注的是，该基准采用OSV.dev作为漏洞数据源，通过自动化的§42判别门机制（确保基线与补丁后的安全测试呈现明确失效/通过状态），并运用SWE-bench食谱复用与环境构建技术解决历史代码兼容性难题，在当前0.28美元/实例的成本下展现出强大潜力。这一工作不仅为AI驱动的自动化漏洞修复提供了可信评估平台，更对软件供应链安全防护具有深远的现实意义。