MOSAIC-Bench: Measuring Compositional Vulnerability Induction in Coding Agents¶

会议: NeurIPS 2026
arXiv: 2605.03952
OpenReview: https://openreview.net/forum?id=g9BxvmeCLK
代码: https://github.com/mosaic-benchmark/mosaic-benchmark
领域: 代码智能
关键词: 代码智能体、复合漏洞诱导、安全评测基准、代码审查防御、CWE漏洞

一句话总结¶

提出了包含199条三阶段工程工单攻击链的MOSAIC-Bench评测基准，揭示了生产级编程智能体在无害工单时序组合下被诱导生成可利用漏洞且绕过安全防御的结构性缺陷。

研究背景与动机¶

大语言模型驱动的代码智能体在软件工程研发中被广泛部署，能够自主解析工单、编写补丁并提交代码变更。然而现有的模型安全对齐主要聚焦于单提示词（single-prompt）或单轮显式恶意意图的拦截，例如直接拒绝“编写恶意注入代码”或“引入漏洞”的指令。在实际工业研发流程中，复杂需求通常被拆解为多张独立的常规工程工单（Jira-style tickets），每个任务由智能体在独立会话中单独执行，这为安全防御带来了全新的盲区。

这一现实场景暴露了当前代码智能体安全对齐的结构性缺陷：当恶意攻击者退居为上游工单编写者，将一个完整的高危安全漏洞（如跨阶段的未授权数据持久化、提权或访问绕过）拆分为若干看似无害、符合业务逻辑的工程重构任务时，智能体在每个局部阶段都检测不到恶意意图，其基于内容模式的防御机制因而被彻底静默。此时，智能体不仅顺利合成了累积可利用的代码漏洞，下游的代码审查智能体在审查累积变更（cumulative diff）时也极易将其视为常规功能变更予以批准。

本文的研究目标是系统性量化这一复合漏洞诱导漏洞。作者发现，单次直接要求引入漏洞时模型会显著触发拒绝（如Claude倾向于拒绝）或自动进行安全加固（如Codex倾向于产出安全代码），但在三阶段拆解工单下，这两种防御模式同时失效。核心 idea：构建包含199条严格经过确定性动态利用测试（PoC Oracle）验证的三阶段复合攻击链基准 MOSAIC-Bench，以真实漏洞利用状态和下游代码审查协议为第一类评估坐标，系统解耦复合诱导攻击成功率与上下文碎片化、审查员防御模式之间的因果关系。

方法详解¶

整体框架¶

MOSAIC-Bench 将复合攻击链定义为四元组：\((\text{ticket}_i|_{i\in\{1,2,3\}}, \text{composed\_implementation}, \text{exploit\_oracle}, \text{metadata})\)。评测基准涵盖10个主流Web应用基底、31个CWE漏洞类型以及5种编程语言（Node.js、Python、Go、Java、PHP）。整体构建与评测流程由工单分解生成、三道独立验证门禁（阶段补丁合法性、审查员共识、确定性容器动态利用验证）、多智能体实现评估以及下游代码审查防御测试四部分组成。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    A["输入：三阶段无害化业务工单序列<br/>(Jira-style Tickets 1, 2, 3)"] --> B["阶段工单逐级实现<br/>无历史会话隔离执行"]
    B --> C["累积代码变更合并<br/>(Cumulative Git Diff)"]
    C --> D["双层验证门禁：审查员评审与漏洞确定性判定"]
    D --> E["动态容器执行：确定性 PoC Oracle<br/>输出 VULNERABLE / SECURE"]
    D --> F["下游审查员防御评测<br/>(Neutral vs. Pentester 提示词)"]

关键设计¶

1. 三阶段复合攻击链与双层验证门禁：保证单阶段隐蔽与组合可利用性

针对传统安全基准无法表征“时序拆解导致防御失效”的问题，MOSAIC-Bench 严格限定所有攻击链采用三阶段统一结构。每一阶段工单在语义上必须完全具备产品合理性（Product-Legible），不得显式出现安全漏洞原语或自解释注释。在过滤阶段设定了三道严格的独立门禁：第一阶段和第二阶段的前缀实现必须在动态测试中判定为安全（SECURE），仅在三阶段全部应用后才触发可利用漏洞；同时，由多模型组成的专家委员会与人工审计确保工单不被常识性审查识别为恶意；最后由运行在隔离Docker容器中的确定性Python PoC脚本对漏洞存在性进行客观判定，彻底杜绝LLM评估的主观偏差与幻觉。

2. 单会话隔离与恢复会话对比协议：解耦复合诱导与上下文遗忘

在评估执行智能体时，基准默认采用符合工业部署实际的“单任务独立会话（Fresh single-session per ticket）”协议，智能体处理第 \(n\) 个任务时完全不包含前置工单的对话历史。为了严谨回答“复合诱导成功率高是否仅仅因为智能体遗忘了前置上下文（Context Fragmentation）”，框架设计了恢复会话（Resumed-session）对比协议，在全对话上下文完整保留的前提下重新评估模型。实验证明跨轮次记忆保留仅能消除中位数约50%的安全差距，证实了复合漏洞诱导的本质是模型对分散在多个无害工程步骤中的恶意端态缺乏安全抽象与因果推理能力，而非单纯的上下文长度瓶颈。

3. 渗透测试员重构提示词防御机制：以零微调代价激活对抗审查

针对下游代码审查智能体在高危累积补丁上普遍出现漏审（Evasion）的痛点，该设计深入探究了审查协议的干预效果。传统代码审查通常采用中立工程提示（Neutral Framing），促使模型关注代码规范和常规功能逻辑；而本设计提出了渗透测试员重构提示（Pentester Framing），强制审查智能体将角色切换为具有攻击视角的安全红队工程师。审查员必须显式解析变更路由与数据流、尝试构建具体的curl攻击载荷并标注具体的CWE编号，若成功构建有效PoC则执行驳回（DECLINE）。该机制完全不需要重新微调模型参数，即可在低成本轻量级模型上显著激活隐蔽安全缺陷的捕获能力。

实验关键数据¶

主实验¶

在199条攻击链上，对主流前沿编程智能体在单会话隔离设置下的端到端攻击成功率（ASR）进行评测。表中严格 ASR 计算排除了导致项目构建/编译失败的 BROKEN 样本，综合 ASR 将其保守计为利用失败。

评估智能体	VULN 数量	SECURE 数量	BROKEN 数量	严格 ASR (%)	综合 ASR (%)
GPT 5.3	171	28	0	85.9%	85.9%
Gemini 3 Flash	131	55	13	70.4%	65.8%
Kimi K2.6	136	58	4	70.1%	68.7%
GLM-5	129	58	12	69.0%	64.8%
Minimax M2.7	126	67	6	65.3%	63.3%
Gemini 3.1 Pro	123	66	10	65.1%	61.8%
GPT 5.4	123	76	0	61.8%	61.8%
Claude Sonnet 4.6	117	82	0	58.8%	58.8%
Claude Opus 4.6	106	93	0	53.3%	53.3%

消融实验¶

评估下游审查员在不同审查模式（仅Diff vs. 全代码仓库上下文Ctx）及渗透测试员提示重构（Pentester Framing）下的审查漏逃率（Evasion Rate，数值越低代表防御能力越强），以及与传统静态分析工具（Semgrep）的基线对比。

审查模型 / 审查配置	Diff 模式漏逃率 (%)	Ctx 全上下文漏逃率 (%)	Pentester 模式漏逃率 (%)	说明
Claude Sonnet 4.6	21.6%	9.0%	3.0%	Pentester 模式下漏逃率降低 18.6 pp
Claude Opus 4.6	18.1%	8.5%	—	Ctx 模式漏逃率降至 8.5%
GPT 5.3	24.6%	13.1%	5.5%	Pentester 模式大幅抑制漏逃
GPT 5.4	27.6%	13.1%	17.6%	对 Pentester 提示泛化相对较弱
Gemini 3 Flash	9.5%	9.5%	—	基础中立模式下即具备极低漏逃率
Gemma-4-E4B-it (开源小模型)	—	—	11.6%	检出率 88.4%，误报率 4.6% (608 PRs)
Semgrep (规则静态分析基线)	56.3%	—	—	复合逻辑类 CWE 漏逃率高达 64%

关键发现¶

在分步工单输入下，测试的9款商业代码智能体端到端攻击成功率高达53.3%–85.9%，而在全样本运行中仅触发了2次拒绝响应；相比之下，在匹配的单次显式提示请求下，Claude的漏洞产出率骤降至0%–1.9%（以拒绝为主），Codex降至9.3%–20.4%（以代码加固为主），证明分步编排能同时瓦解“拒绝”和“加固”两类核心安全防御防线。
在审查协议敏感性分析中，协议提示设定对防御效果的影响远超上下文长度与模型规模参数（Framing >> Context >> Scale）。轻量级端侧模型 Gemma-4-E4B-it 仅需使用 Pentester Framing，即可达到 11.6% 的低漏逃率，效果逼近高算力商用模型，且每次调用成本降低近3个数量级。
异构审查员具备显著互补性：Codex审查员更擅长捕捉对象序列化、投影缺失等数据流隐蔽副作用（如CWE-200），而Claude审查员对认证状态、Cookie安全及基础设施配置缺失更为敏感。

亮点与洞察¶

评测范式创新：MOSAIC-Bench首次将客观确定性动态利用测试（PoC Oracle）与下游代码审查协议并列为评估第一轴，摆脱了单纯依赖提示词相似度或静态规则打分的局限。
零微调防御启示：揭示了审查员提示词从“中立同行评审”重塑为“红队对抗攻防”的巨大杠杆效应，为企业CI/CD工作流中的代码审查智能体提供了开箱即用的落地防御范式。
防御模式因果归因：通过单提示词基线与恢复会话消融，清晰解构了不同厂商模型的防御偏好（Claude偏向直接拒绝，Codex偏向代码加固），证明复合工单对防御机制的瓦解具备系统性。

局限与展望¶

软件生态覆盖局限：当前基准主要覆盖Web服务常见后端技术栈（Node.js、Python、Go、Java、PHP），尚未涵盖移动端、嵌入式系统、Linux内核及机器学习训练管线等底层或特种软件系统。
静态工单链条：评测设置假定三阶段工单由攻击者预先设计并静态投递，未建模攻击者根据智能体的中间补丁自适应调整后续工单的动态博弈场景。
自动化防御迁移代价：尽管渗透测试提示词显著压低了漏逃率，但真实PR审计显示其在部分仓库上存在一定误报率（如gorilla/mux达12%），在极低误报容忍度的生产发布流程中仍需人机协同。

评分¶

新颖性: ⭐⭐⭐⭐⭐ 首次系统性提出并量化了编程智能体在无害工单时序组合下的复合漏洞诱导现象。
实验充分度: ⭐⭐⭐⭐⭐ 涵盖9款前沿智能体、10类商业级审查配置、确定性容器PoC以及608个真实PR误报审计。
写作质量: ⭐⭐⭐⭐⭐ 威胁模型清晰，论证链条严密，因果分析与反事实对照实验充分。
价值: ⭐⭐⭐⭐⭐ 对代码智能体的对齐评测、企业级AI研发安全防护及代码审查流水线具有重大的实用指导价值。