技术摘要：SEC-bench Pro

问题陈述

大型语言模型（LLM）正越来越多地部署于自动化软件安全任务中，包括漏洞发现和概念验证（PoC）生成。然而，现有的基准测试无法在真实的漏洞挖掘场景中忠实评估 LLM。当前的评估方法存在三个主要差距：

1. 模糊测试 harness 依赖：许多基准测试（例如 ARVO、CyberGym）依赖模糊测试 harness，这将可执行入口点限制为特定的内部接口。这衡量的是由 harness 引导的输入变异能力，而非通过公共接口审计代码的能力。
2. 特定目标或基于模式的评分：现有指标通常将生成的证据与已知补丁、退出代码或崩溃签名进行比较。这将预期漏洞的复现与同一历史版本中无关的崩溃混为一谈，或者拒绝产生不同执行轨迹的有效 PoC。
3. 过度信息暴露：当前基准测试中的任务输入通常包含 sanitizer 报告、函数名、行号或触发路径。这消除了安全工程师在审计代码时面临的不确定性，为智能体提供了它们在真实场景中本不会掌握的信息。

因此，需要一个基准测试，能够在现实条件下衡量智能体在关键、高复杂度软件系统上的漏洞挖掘能力，要求跨执行层级进行推理，且不依赖模糊测试基础设施或过度暴露的元数据。

方法论

作者提出了 SEC-bench Pro，这是一个旨在衡量智能体在 JavaScript 引擎（具体为 V8 和 SpiderMonkey）上进行漏洞挖掘的基准测试及构建流水线。该系统采用三阶段、自演进的流水线，将披露的安全报告转化为可复现、已验证的任务。

1. 报告收集

该流水线从项目特定的追踪器（Chromium 问题追踪器、Mozilla Bugzilla）和精选的咨询 feed（MFSA、Pwn2Own、CISA KEV）中摄入结构化的安全报告。它筛选标记为 sec-high 或 sec-critical（或符合赏金资格）的报告，这些报告必须包含具体的 PoC 工件以及关联的修复提交。

2. 智能体驱动的环境重构

为了解决重构历史易受攻击环境的劳动强度问题，该流水线将此任务委托给自主编码智能体。

• 输入：智能体接收原始漏洞报告、PoC 工件，以及一个结构化提示，指定目标二进制文件、允许的标志和预期的错误类型。
• 过程：智能体驱动项目的构建系统，在特定的报告修订版上生成已插桩的二进制文件，并配置适当的 sanitizer（例如 ASan）或调试检查。
• 输出：智能体生成一个包含易受攻击和修复版 Dockerfile、结构化元数据、标准 PoC 以及捕获的崩溃签名的 Docker 工件包。提示明确禁止伪造输出。

3. 自动化验证预言机

在实例进入数据集之前，必须通过两个自动化预言机：

• 易受攻击镜像预言机：在重构的容器中多次运行 PoC。它根据项目特定的分类法（例如 ASAN_CRASH、SANDBOX_VIOLATION、DCHECK）对崩溃进行分类。仅当执行产生与预期错误类型匹配的崩溃时，实例才算通过。
• 修复镜像预言机：应用关联的补丁，重新构建二进制文件，并运行相同的 PoC。它验证补丁是否抑制了收集的 PoC（将结果分类为 BLOCKED_DEFENSIVE、BLOCKED_HARMLESS 或 BLOCKED_NO_REPRO）。仅当 PoC 在修复后不再复现时，实例才算通过。

评估与评分

评估使用三镜像评分流水线（易受攻击、修复和最新上游镜像）以及LLM 作为裁判来确定成功与否。

• 执行：候选 PoC 在所有三个镜像上重放。
• 判定：LLM 裁判分析退出代码、stdout 和 stderr，将结果分类为三个类别：
  • 已验证：易受攻击镜像显示与目标匹配的崩溃；修复/最新证据不与此归因相矛盾。
  • 不确定：证据不完整（例如，修复/最新运行中的基础设施故障），需要人工裁决。
  • 非法：崩溃与目标不匹配，或者修复/最新镜像显示崩溃因不同的根本原因而持续存在。
• 成功指标：如果至少一个候选 PoC 获得 verified 结果，则该实例成功。这种方法防止了“仅崩溃”的膨胀，即智能体触发无关的崩溃。

主要贡献

• SEC-bench Pro 数据集：包含 183 个已验证漏洞的集合，涵盖 V8（103 个实例）和 SpiderMonkey（80 个实例）。V8 子集包括累计 Google 漏洞奖励计划奖金超过 150 万美元的报告。
• 自演进流水线：一个参数化的构建流水线，可以摄入新的 PoC 支持和补丁支持的报告，而无需重新设计基准测试，适用于任何具有源代码级构建配方和公开报告的项目。
• 三镜像评分预言机：一种稳健的评估方法，能够区分预期的漏洞复现与无关的崩溃或基础设施故障，解决了仅依赖崩溃或仅依赖补丁匹配评分器的局限性。
• 综合智能体评估：对三种最先进的编码智能体框架（CODEX、CLAUDECODE、OPENCODE）在长视野安全任务上的评估。

结果

对前沿模型和开放权重基线的评估揭示了当前在长视野漏洞挖掘能力方面的显著局限性：

• 低成功率：即使是最强的配置，在两个引擎上的成功率也仍低于 40%。
  • V8：最强的单一配置（CODEX 配合 GPT-5.4）达到 32.0%（33/103）。开放权重的 Kimi-K2.6 基线达到 11.7%。
  • SpiderMonkey：最强的配置（CLAUDECODE 配合 Opus 4.6）达到 38.8%（31/80）。
• 互补覆盖：智能体解决的实例集 largely 互不重叠。CLAUDECODE 和 CODEX 的并集在 V8 上达到 37.9%，在 SpiderMonkey 上达到 48.8%，表明没有单一的智能体策略能主导所有漏洞类别。
• 策略差异：
  • CLAUDECODE 采用高广度策略，生成大量推测性 PoC，但每个 PoC 的产出率较低。它经常失败，因为 PoC 从未触发崩溃（干净的退出代码）或触发了无关的崩溃。
  • CODEX 采用高选择性策略，生成较少但置信度更高的 PoC。它经常失败，因为它在无法在本地验证可达性时选择放弃提交，或者其 PoC 触发的崩溃未被补丁完全缓解（部分修复冲突）。
• 失败成本：失败的运行持续消耗比成功运行显著更多的 token 和运行时间（例如，CLAUDECODE 在 V8 上的 token 差距为 3.0 倍），表明长时间的探索往往导致收益递减，而非更深入的分析。
• 归因的重要性：一个“仅崩溃”评分器会将所有配置的成功率虚增约 43.6%，突显了三镜像 LLM 裁判过滤错误归因崩溃的必要性。

意义

本文确立了 SEC-bench Pro 作为衡量自动化软件安全进展的具体、可复现的目标。它表明，虽然 LLM 可以辅助漏洞发现，但当前的前沿模型难以应对生产级引擎上长视野漏洞挖掘的复杂性。该基准测试揭示了具体的局限性，包括合成复杂触发条件（例如特定的 JIT 状态、沙箱绕过）的难度，以及失败探索的高昂成本。作者得出结论，未来的系统需要更强的触发合成、更稳健的归因机制以及集成搜索策略，以缩小当前能力与现实世界安全审计需求之间的差距。