AutoBaxBuilder: Bootstrapping Code Security Benchmarking¶

会议: ICML2026
arXiv: 2512.21132
代码: https://github.com/eth-sri/autobaxbuilder
领域: 代码智能 / 安全评测
关键词: 代码安全评测, LLM生成代码, 自动基准构建, 端到端安全测试, BAXBENCH

一句话总结¶

AUTOBAXBUILDER用LLM代理流水线自动生成Web后端安全评测场景、功能测试和端到端安全测试，把人工构建BAXBENCH式任务的成本降低约12倍，并构建出40个新场景的AUTOBAXBENCH来评估当代代码模型的正确性与安全性差距。

研究背景与动机¶

领域现状：LLM已经被广泛用于软件工程，尤其是生成Web后端、API服务和应用逻辑。传统代码生成评测常看功能正确性，例如单元测试是否通过；安全评测则依赖静态分析器、人工审查或安全专家手写端到端攻击测试。BAXBENCH这类基准进一步要求模型生成完整后端，并同时接受功能测试和安全测试。

现有痛点：安全基准的人工构建成本很高。一个场景不只是需要自然语言规格和OpenAPI接口，还需要功能测试、参考实现、可复现的安全测试和人工验证。随着模型能力提升，旧基准容易被训练污染，也容易过于简单；但持续扩展高质量安全基准需要大量专家时间。

核心矛盾：自动生成基准可以降低成本并提高更新频率，但安全测试本身必须可靠。一个自动生成的测试如果误报安全问题，会低估模型能力；如果漏掉漏洞，又会让不安全代码通过。因此，自动化流水线必须同时解决新场景生成、功能一致性验证和安全测试精确性验证。

本文目标：作者希望构建一个从零开始生成BAXBENCH风格任务的流水线，让它能自动提出后端服务场景、生成功能测试、构建安全测试，并通过执行反馈和参考解的对比来过滤错误测试。最终目标是快速构建可公开发布、难度可控、覆盖多类CWE的代码安全基准。

切入角度：论文把基准构建拆成一个多阶段代理工作流。编排模型负责提出场景、生成测试、分析潜在漏洞并迭代修正；多个解题模型生成参考实现，用执行日志为测试和安全检查提供反馈。流水线不断寻找“功能正确但安全状态不同”的对照实现，以确认安全测试不是只会攻击某个偶然实现。

核心 idea：用LLM生成候选基准，再用执行反馈、参考解分歧、对照实现和人工抽检层层校准，使自动生成的安全测试接近专家手写测试的可靠性，同时显著降低构建成本。

方法详解¶

AUTOBAXBUILDER生成的是完整的安全评测实例，而不是单条代码题。每个实例包含一个后端服务场景、REST API规格、功能测试和安全测试。评测时，模型需要为该后端生成可运行实现，系统把实现放进隔离容器，通过REST接口运行功能测试和安全测试。指标包括只看功能正确的pass@1，以及同时功能正确且未被安全测试击中的sec_pass@1。

整体框架¶

流水线由一个编排LLM和若干解题LLM组成。第一步，编排LLM根据目标难度、已有场景名称和示例CWE提出新后端服务，生成OpenAPI规格和文本说明，并检查场景新颖性。第二步，解题LLM为该场景写参考实现，编排LLM基于规格生成功能测试，再通过运行测试和检查日志来修正测试或修正参考实现。第三步，编排LLM分析场景和参考实现中的潜在安全弱点，生成安全测试，并通过安全/不安全对照实现验证测试是否能正确区分。

这个过程大量依赖执行反馈。OpenAPI规格会用YAML验证器检查，测试和安全测试代码会用Python编译检查，输出格式还会经过正则约束。每个 refinement loop 最多运行5次；如果安全测试持续无法稳定验证，就丢弃该测试。论文还加入伪随机flag、文件系统/数据库/资源监控等辅助函数，让端到端安全检查可以程序化判断结果。

关键设计¶

场景与参考实现自举:
- 功能：从零生成新的Web后端安全评测任务，并为后续测试迭代提供可执行对象。
- 核心思路：编排LLM先提出一个有清晰攻击面的服务场景，生成OpenAPI接口和文本规格；随后多个解题LLM生成参考实现。场景生成会避开已有BAXBENCH场景和已经生成过的场景，以降低重复和污染风险。
- 设计动机：安全基准需要不断扩展，否则会被模型记住或被能力增长冲平。让场景本身可自动生成，并用不同模型产出的参考实现来暴露规格歧义，是降低构建成本的第一步。
功能测试与实现的交替 refinement:
- 功能：确保功能测试真正表达规格要求，而不是和某个错误参考实现共同过拟合。
- 核心思路：流水线先让编排LLM抽取功能需求并生成测试。如果测试失败，REFINESOLUTIONS阶段只给模型看失败实现的执行日志，不展示测试代码，避免模型直接迎合测试。REFINETESTS阶段再综合测试代码、实现代码和日志，判断是测试逻辑错、实现错还是规格歧义，并据此修正。
- 设计动机：自动基准最怕“测试-实现共谋”：测试写错了，但某个实现碰巧通过。交替修正和全局共识判断能减少这种漂移，让测试更接近规格本身。
安全测试的对照验证:
- 功能：让生成的安全测试既能发现真实漏洞，又尽量避免把安全实现误判为不安全。
- 核心思路：编排LLM先从场景和功能正确参考实现中识别潜在CWE，然后为目标漏洞生成安全测试。REFINEEXPLOIT会在原参考实现和修改后的对照实现之间反复运行测试：若一个实现被判为不安全，流水线会尝试构造修复版；若一个实现被判为安全，流水线会尝试构造引入目标漏洞的版本。安全测试只有在正负对照中都符合预期时才被保留。
- 设计动机：端到端安全测试的价值在于具体、可复现、低误报。对照实现让流水线有机会验证测试关注的是目标安全属性，而不是某个框架细节或未指定行为。

损失函数 / 训练策略¶

本文不是训练新模型，而是设计一个基准生成和评测流水线。编排模型主要使用GPT-5，参考实现来自GPT-5、Claude 4 Sonnet、DeepSeek-R1和Qwen3 Coder 480B等模型；最终评测覆盖14个代码模型家族或版本，并要求它们在14种框架、6种语言环境中生成实现。

评测指标沿用BAXBENCH：pass@1表示功能测试全通过的比例，sec_pass@1表示功能测试和安全测试都通过的比例。AUTOBAXBUILDER构建测试时默认参考实现使用Python-FastAPI，但附录用JavaScript-Fastify和Go-Gin做框架消融，结果显示模型排序和CWE覆盖总体稳定。

实验关键数据¶

主实验¶

作者先在28个BAXBENCH场景上验证自动生成的测试和专家手写测试是否给出相近趋势，再构建40个新场景的AUTOBAXBENCH。下表总结AUTOBAXBENCH的规模、难度和最佳模型成绩。

数据集	场景数	平均端点数	平均规格长度	平均CWE数	最佳sec_pass@1	最佳pass@1
BAXBENCH	28	1.9	430	3.3	60%	81%
AUTOBAXBENCH Easy	10	1.0	587	1.6	36%	81%
AUTOBAXBENCH Medium	20	3.0	1006	2.7	40%	84%
AUTOBAXBENCH Hard	10	4.7	1516	3.5	25%	83%
AUTOBAXBENCH Overall	40	2.93	1029	2.6	36%	83%

消融实验¶

论文给出多组稳定性分析：自动测试与专家测试的一致性、参考框架变化、代理式harness、生成模型选择和人工评估。下表整理关键消融结果。

配置	关键指标	说明
AUTOBAXBUILDER测试 vs BAXBENCH功能测试	80.9%解级一致	功能正确性趋势高度接近，并发现BAXBENCH中2个错误测试和2个歧义规格
AUTOBAXBUILDER安全测试 vs BAXBENCH安全测试	在共同功能正确解中额外标记512个不安全解	自动生成测试更严格，覆盖更多CWE和攻击变体
手工审计71个自动安全测试	仅1个不可靠测试	自动生成安全测试整体质量较高
参考框架消融	排名和CWE覆盖稳定	Python-FastAPI、JavaScript-Fastify、Go-Gin生成的测试给出相似趋势
生成模型消融	pass@1 ρ=0.93, sec_pass@1 ρ=0.91	使用不相交模型集生成的替代基准仍保持强排序相关
代理式harness	远未接近100%安全通过	GPT-5有所提升，Claude 4.5 Sonnet不稳定，说明工具增强不能消除安全缺口

模型表现与成本¶

AUTOBAXBENCH显示，最强模型的功能正确率已经很高，但安全正确率仍明显落后。

项目	数值	含义
Claude 4.5 Sonnet overall pass@1	82.7%	很多实现功能上能跑通
Claude 4.5 Sonnet overall sec_pass@1	36%	同时功能正确且安全的比例仍低
Claude 4.5 Sonnet Hard sec_pass@1	25%	多端点复杂后端显著更难
构建40个AUTOBAXBENCH场景总API成本	<160美元	平均每场景约3.9美元
自动生成单场景时间	约2小时	可跨场景并行
人工工作量	每场景约15分钟验证	相比约3小时人工构建减少约12倍

关键发现¶

AUTOBAXBUILDER在BAXBENCH原场景上复现了专家测试的模型排序，但安全测试更严格，说明自动流水线不只是抄近似功能测试，还能扩展安全覆盖。
AUTOBAXBENCH比BAXBENCH整体规格更长、端点更多，并能按Easy、Medium、Hard控制难度。Hard子集上最佳模型sec_pass@1仅25%，暴露出现代代码模型在复杂后端安全上的明显短板。
pass@1和sec_pass@1差距很大。以Claude 4.5 Sonnet为例，整体功能正确率约82.7%，但安全且正确只有36%，说明“能实现功能”和“安全实现功能”仍是两个不同能力。
生成成本主要花在功能测试和安全测试的refinement输出token上，漏洞分析和策略生成约占17%的token预算。运行参考实现和测试本身几乎不产生API成本。

亮点与洞察¶

论文把安全基准构建本身工程化了。它不只让LLM写题，还要求场景、功能测试、安全测试和正负对照实现形成闭环，这是自动基准可信度的关键。
“安全测试比专家更严格”这个结果很有意思。自动流水线通过多参考实现和反复执行，可能发现专家初版基准没有覆盖的CWE和变体，从而反过来帮助维护已有基准。
难度可控是实用亮点。通过调节端点数和场景复杂度，AUTOBAXBUILDER可以随着模型能力增长生成更难任务，避免基准很快饱和。
对代码智能研究来说，本文提醒评测不能只看pass@1。一个能通过功能测试的Web后端依然可能有严重安全问题，sec_pass@1更接近真实部署风险。

局限与展望¶

自动生成的安全测试并非完全无误，人工审计仍发现少量不可靠案例，尤其是资源耗尽类测试容易踩到规格未定义区域。因此论文主实验排除了CWE-400，并在附录单独分析。
参考实现主要用Python-FastAPI生成，虽然框架消融显示趋势稳定，但跨语言、跨框架的细节差异仍可能影响某些CWE覆盖。
AUTOBAXBUILDER依赖强编排模型和大量执行反馈，成本已经较低但仍需要复杂基础设施，包括容器运行、API服务启动、数据库/文件系统检查和日志解析。
LLM生成基准存在潜在自偏置风险。论文用不相交模型集和中立模型校准未观察到系统偏置，但这类风险需要长期跟踪，尤其当生成模型和被评测模型来自同一训练生态时。
后续可以加入更强的人类审查界面、覆盖更多真实框架和云服务场景，并把生成出的安全测试反馈给开发工具，用于训练或约束代码生成模型。

评分¶

新颖性: ⭐⭐⭐⭐⭐ 把LLM代理用于自动生成端到端代码安全基准，并用对照实现验证安全测试，思路完整且实用。
实验充分度: ⭐⭐⭐⭐⭐ 包含原基准复现、40个新场景、模型大规模评测、框架消融、模型消融和人工审计，证据非常足。
写作质量: ⭐⭐⭐⭐ 主线清晰，附录信息量丰富，但表格和图很多，读者需要在主文与附录之间切换才能掌握全部验证细节。
价值: ⭐⭐⭐⭐⭐ 对代码LLM安全评测、基准抗污染和持续难度更新都有直接价值，也能作为构建其他领域自动评测基准的范式。