CheckerBench: 长程智能体能否合成静态分析检查器?

TL;DR CheckerBench 用 300 个真实 CVE 任务评估智能体从零合成静态分析检查器，21 种模型/哈尼斯配置平均 Pass@1 仅 32.30%（最佳 45.33%），揭示长程代码生成仍远未达到可靠可复用水平。

问题

问题背景

当前 AI 编码代理领域正从短程补丁生成向长程、仓库级软件工程任务扩展，如漏洞修复、测试生成与代码审查。然而，静态分析检查器(static-analysis checker)的自动合成仍未得到系统评估，现有基准大多聚焦其他编码能力。

现有方法局限

现有编码代理基准(如 SWE-bench、HumanEval)主要评估补丁生成、漏洞检测或单函数代码编写，很少要求代理在真实仓库中从零开发可用的静态分析检查器。这类任务需要代理解释缺陷规范、理解特定静态分析框架(如 CodeQL、Semgrep)的内部表示，编写规则逻辑，并通过反复编译与分析反馈来迭代细化。现有基准通常只关注最终输出(如补丁是否通过测试)，而忽略这一长程、多步、工具交互过程，因此无法衡量代理在实际安全检查器开发中的真实能力。

为什么这个问题难/重要

静态分析检查器合成是安全工具链的关键环节：一个高质量检查器可在大规模代码库中自动发现同类缺陷，而人工编写成本高、周期长。技术挑战包括跨语言与跨缺陷类型(85 个 CWE)的泛化、分析框架规则语言的差异，以及需要精确区分易受攻击与已修复版本(vulnerable-fixed contrast)。业界对自动化安全规则生成需求强烈，因为漏洞模式不断演变，人工规则维护难以跟上。若代理能可靠合成检查器，将显著提升软件安全防护的自动化水平，减少人工审计负担。

行业类比

这类似于让 AI 代理从安全公告自动生成 CI/CD 流水线中的扫描规则，将漏洞知识直接转化为可执行检测逻辑，就像从代码审查意见自动生成 lint 规则。

核心洞察

• CheckerBench 是首个将静态分析 checker 合成作为长周期、可执行、仓库级 agent 任务的端到端基准。与现有编码基准(如 SWE-bench 侧重补丁生成、漏洞检测基准侧重发现漏洞位置)不同,CheckerBench 要求 agent 从缺陷规格出发,理解分析框架 API,编写可编译的 checker 规则,并依据编译和分析反馈反复迭代,最终在独立环境中重建并验证其对漏洞/修复版本的区分能力。这一全流程覆盖了静态分析工具开发的核心步骤,且基准构建包含人工引导轨迹和污染审计,使结果更具参照性。
• CheckerBench 引入的 CheckerLab 评估框架以 vulnerable-fixed diagnostic contrast 为核心指标,衡量 checker 区分漏洞与修复版本的能力,而非仅看生成代码的正确性。传统代码生成基准常用 pass@k 或单元测试指标,但静态分析 checker 的价值在于对真实代码库中特定缺陷模式的精确检测,需同时关注召回的漏洞定位和误报控制。CheckerBench 通过独立重建、patch localization 和 false positives 测量,揭示了当前模型在长周期 checker 开发上的不足(均值 Pass@1 仅 32.30%,最佳 45.33%),凸显了现有 agent 在生成可复用、低误报的静态分析规则上的能力边界,为后续研究提供了明确的改进方向。

方法

输入

CheckerBench 以真实 CVE 记录为起点，每条任务包含三部分：

• 漏洞与修复版本：来自 297 个 CVE，覆盖 167 个仓库、85 个 CWE、5 种语言生态（如 Python、Java、C/C++、JavaScript、Go）。
• 固定分析环境：预构建的静态分析框架依赖与构建脚本，确保 checker 可在隔离容器中编译运行。
• Checker 脚手架：提供目标分析器（如 CodeQL、Semgrep 等）的模板文件与任务描述，agent 需补充规则逻辑。

关键模块

基准构建（六阶段）：

1. 漏洞源收集：从公开漏洞库抓取 vulnerable/fixed 提交对，解析 diff 与仓库元数据。
2. 可执行环境重建：为每个任务恢复可构建、可运行的分析器环境，锁定版本与依赖。
3. 任务构建：将缺陷规范转化为 checker 合成任务，附带脚手架与指令。
4. 独立验证器构建：编写自动化测试程序，用于评测提交 checker 的正确性。
5. 人工引导 rollout 收集采样：由人类专家运行少量示范轨迹，用于校准任务难度与交互预算。
6. 质量控制、去重与划分：过滤不可复现任务，按仓库/语言去重，划分 train/test 集。

CheckerLab 评估框架：

• 工作流：独立重建 agent 提交的 checker（不依赖 agent 环境），在冻结的 vulnerable/fixed 版本上运行。
• 指标：
  • 诊断对比度：vulnerable 与 fixed 版本的告警差异是否反映缺陷消除。
  • 补丁定位：告警是否指向补丁修改的相关代码位置。
  • 误报率：在 fixed 版本或无关代码上的告警数量。
  • 工具使用效率：统计编译、分析、修复循环次数与 token 消耗。

输出

最终输出为 300 个可执行任务及其评测结果（如 Pass@1、误报率、语言与 CWE 维度分数）。

与同类 coding-agent 基准（如 SWE-bench、Defects4J）不同，CheckerBench 要求 agent 从头开发可复用的静态分析规则，而非生成一次性补丁或简单漏洞检测脚本，更贴近长期维护型工程任务。

实验

实验设计

CheckerBench 包含 300 个任务，源自 297 个 CVE、167 个仓库、85 个 CWE 和 5 个语言生态系统。评估框架 CheckerLab 独立重建提交的 checker，并测量 vulnerable-fixed diagnostic contrast、patch localization、false positives、tool use 等指标。实验覆盖 21 个模型-框架配置，每配置独立重复 3 次。

关键发现

平均 Pass@1 为 32.30%，最佳配置达 45.33%。这表明当前编码代理在开发可靠、可复用的静态分析 checker 方面仍面临显著困难。诊断质量、误报率、不同语言和缺陷族之间表现差异明显，模型与框架的选择对成功率影响很大。

基线对比解读

CheckerBench 与现有编码代理基准不同，它要求代理从零开发 checker，而非生成补丁或检测漏洞，因此任务难度更高。最佳 45.33% 虽高于平均，但仍未达到实用水平。选择适合的模型和框架组合是实际工程中提升效率的关键，当前整体性能仍需大幅提升。

行业影响

落地场景

CheckerBench 评估的静态分析检查器合成能力可应用于 DevSecOps 工具链、代码托管平台和云安全产品。例如，代码审查系统可集成代理自动为特定 CWE 或 CVE 生成定制检查器，减少人工编写规则时间。安全团队可为内部框架生成针对性的污点分析规则，覆盖通用 SAST 工具遗漏的模式。

商业价值

自动化检查器合成有望降低安全规则开发成本。传统上，编写高质量 CodeQL 或 Semgrep 规则需要同时精通安全与编译器 AST 的专家，单位成本高。代理若能有效合成，则可缩短新漏洞披露后的规则落地周期，提升检测覆盖率，降低因漏报导致的安全事件损失。Benchmark 显示最佳 Pass@1 仅 45.33%，说明当前代理仍需人类审核，但可作为辅助降低规则编写门槛，让普通开发者也能产出可用的检查器初稿。

与现有工作流的集成

CheckerBench 的评估框架 CheckerLab 提供了独立重建和指标衡量方法，可作为企业在采购或自研代码代理时的基线测试集。实际集成时，可将代理作为规则生成后端，嵌入 Semgrep、CodeQL、SonarQube 等 SAST 工具链，通过 CI 管线自动触发生成规则、人工确认后进入规则库。代理输出可直接转为 Checker 代码，配合现有扫描工作流。

具体用例

• 金融科技：信用卡支付网关服务使用代理为内部资金流转函数生成不变量检查器，防止因重构引入的资金计算漏洞。
• 电商平台：大促前安全团队用代理针对订单金额修改、优惠叠加逻辑生成定制化安全规则，部署到预发布阶段的 SAST 扫描中。

局限

• 任务取样于 CVE，缺陷类型集中于安全漏洞，如越界读写、注入等，而静态分析检查器在真实工程中还常用于检测资源泄漏、并发缺陷、API 误用等非安全类问题。这导致 CheckerBench 的泛化性受限，模型在 CVE 驱动的任务上表现可能不能迁移到更广泛的缺陷类别。此外，CVE 仓库多为开源项目，使用特定构建系统与语言版本，样本分布不均（如部分语言任务数较少），影响跨语言评估的统计效力。
• 基准要求每个任务能重建可执行环境，但原始仓库的依赖复杂性与构建历史可能导致部分任务无法完全复现，尤其涉及旧版本编译器、私有依赖或特定操作系统。论文虽采用“Executable Environment Reconstruction”，但可能通过降级构建或裁剪依赖来保证可执行，这改变了原始检查器开发条件。同时，固定分析环境（pinned analysis environment）虽保证公平，但限制了模型尝试其他静态分析框架或自定义工具链的可能，与实际开发中灵活选型不符。
• 评估使用 Pass@1 等指标，但长程 agent 交互中基础设施层面的失败（如编译错误、超时、资源限制）可能被误判为模型能力不足。论文虽统计了失败原因，但无法完全隔离环境噪声。另外，数据污染审计依赖公开信息，可能低估了预训练中意外暴露任务细节的风险。这些因素共同导致分数下限可能偏低，而真实建模能力或许略高于报告值。