🤖 AI

DualGauge: Automated Joint Security-Functionality Benchmarking of Specification-Only Code Generation by LLMs and Coding Agents

该论文介绍了 DualGauge，这是一个自动化框架和基准测试，旨在证明当前的 LLM 和编程智能体难以同时生成既具备功能正确性又具备安全性代码，其在多种语言中的联合成功率仍低于 15%，并揭示了增强模型能力或迭代脚手架并不能可靠地解决这些安全性与功能性的权衡问题。

原作者： Rupam Patir, Keyan Guo, Suvadra Barua, Abhijeet Pathak, Dinesh Gudimetla, Jiawei Guo, Hongxin Hu, Haipeng Cai

发布于 2026-06-16

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Rupam Patir, Keyan Guo, Suvadra Barua, Abhijeet Pathak, Dinesh Gudimetla, Jiawei Guo, Hongxin Hu, Haipeng Cai

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你雇佣了一位口若悬河、动作极快的机器人厨师，根据一个简单的口头描述来做饭：“做一个三明治。”

长期以来，我们只检查机器人是否遵循了食谱。它有没有把面包放在盘子里？是的。它有没有加火腿？是的。如果这个三明治看起来没错，我们就说：“做得好！”

但这项名为 DualGauge 的新论文提出了一个更难的问题：“这个三明治可以安全食用吗？”

也许机器人完美地遵循了食谱，但它也可能不小心用抽屉里发现的一把生锈的刀片切了火腿，或者使用了一个从未清洗过的切菜板。这个三明治看起来像个三明治，但它是危险的。

以下是研究人员发现的过程，用简单的语言进行了解释。

1. 问题所在：“看起来不错”的陷阱

研究人员发现，目前的 AI 编程工具（就像这位机器人厨师）非常擅长制作那些“看起来能运行”的东西，但它们非常不擅长制作那些“真正安全”的东西。

他们构建了一个新的测试系统，叫做 DualGauge。你可以把它想象成一个“双重检查厨房”。

旧的方法： 你品尝三明治。如果吃起来有火腿味，你就通过了测试。
DualGauge 的方法： 你品尝三明治（功能性），并且你检查厨房里是否有生锈的刀、脏掉的菜板和毒药（安全性）。

2. 基准测试：“307 份三明治订单”

为了测试这一点，他们创建了一个包含 307 种不同任务 的庞大菜单。

每个任务都只是一个简单的句子，比如“写一个读取文件的程序”。
他们没有给 AI 提供任何提示、代码片段或安全警告。只有一个指令。
对于每一份订单，他们都创建了两套测试：
1. 口味测试： 程序是否完成了它应该做的事情？
2. 安全检查： 程序是否试图窃取文件、导致系统崩溃或让黑客入侵？

3. 令人震惊的结果

他们要求 10 个最聪明的 AI 模型（即“厨师”）制作这 307 份三明治。结果如下：

“看起来不错”的分数很高： 许多模型大约能让 39% 的三明治口味正确。它们遵循了食谱！
“安全”的分数很低： 当检查安全性时，分数下降了。
“完美”的分数微乎其微： 当他们问，“你是否做出了一个既好吃又安全的三明治？”时，表现最好的 AI 模型得分低于 15%。

类比： 想象一个学生在参加数学考试。他答对了 90% 的题目（功能正确性）。但如果你问：“你是否也检查了计算错误？”他就会不及格。论文发现，擅长编程并不自动意味着擅长安全地编程。

4. 为什么“思考得更努力”没有帮助

研究人员尝试通过给 AI 提供更多工具来解决这个问题，就像给厨师更好的刀具或更多的思考时间一样。他们尝试了：

更大的模型： 使用“超级厨师”（更大的 AI 大脑）。
扩展思考： 告诉 AI，“慢慢来，一步步思考”。
专门化训练： 教导 AI 如何专门成为一名程序员。

结果： 这些技巧并不能可靠地解决安全问题。有时 AI 在食谱方面做得更好，但仍然忘记了清洗菜板；有时它在安全性方面做得更好，但却忘了食谱。安全性和功能性是两种不同的技能，它们并不总是同步增长的。

5. “机器人助手”也无济于事

现在有一些新的 AI 工具充当“智能体（agents）”。它们不仅仅是写一次代码，而是尝试修复自己的错误。它们编写代码，运行代码，看到错误，然后再次尝试。

研究人员发现，在这些“纯粹食谱型”任务中，这些智能体的表现并不比简单的机器人好。

原因： 这些智能体把所有时间都花在了寻找厨房里的工具上（比如搜索特定文件或搭建服务器），而不是实际修复三明治的安全性。它们忙于“管理厨房”，而不是“安全烹饪”。

6. “隐藏的危险”

论文发现了一个关于 AI 为何失败的具体模式。

功能性失败： AI 通常是因为回答的“形状”错了而失败（例如，它返回了错误类型的数据）。
安全性失败： AI 通常确实尝试了要保持安全，但做得不完整。
- 例子： AI 给门装了一把锁（保安），但它忘了锁好后窗。保安看起来没问题，但房子依然是不安全的。

核心结论

论文得出结论，我们不能仅仅因为 AI 写出的代码“能用”就信任它。

功能正确性是判断安全性的糟糕测谎仪。 仅仅因为代码运行没有崩溃，并不意味着它是安全的。
我们需要一个新的标准。 我们需要同时测试安全性与功能性，并使用相同的规则。
目前的 AI 还没达到这个水平。 即便是最聪明的模型，也无法持续产生既有用又安全的代码。

简而言之：仅仅因为机器人厨师做出了一个看起来美味的三明治，并不意味着你应该吃它。 我们也需要检查一下厨房。

技术摘要：DualGauge

问题陈述

大语言模型（LLM）及基于 LLM 的编程智能体正越来越多地被用于根据自然语言规范生成代码。虽然功能正确性已成为评估这些系统的主要标准，但对于确保软件的可部署性而言，这还远远不够。先前的研究表明，AI 编程助手经常生成不安全的代码，而开发者在接受这些建议时往往对其安全性保持信心。

现有的评估框架存在两个主要局限性：

指标孤立： 功能基准测试（如 HumanEval、LiveBench）和安全基准测试（如 SecurityEval、CodeLMSec）通常将正确性和安全性在隔离状态下或在不同的数据集上进行评估。一个通过了功能测试但包含漏洞，或者反之亦然的程序是毫无用处的。
评估预言机（Oracle）挑战： 安全评估不能仅仅依赖于精确的输出匹配。正如路径遍历示例所示，一个安全实现与一个脆弱实现可能在对抗性输入上产生相同的输出和退出码。区别往往在于执行轨迹（例如，在检查失败之前是否访问了文件），这需要对运行时行为进行语义推理，而非简单的输出比较。
上下文限制： 大多数基准测试依赖于代码补全、仓库上下文或框架脚手架，忽略了“仅限规范”（specification-only）的生成场景，即模型必须仅根据自然语言描述来实现一个函数。

方法论：DualGauge 与 DualGauge-Bench

作者提出了 DualGauge，这是一个用于联合评估仅限规范代码生成中的安全性和功能性的全自动框架，并由 DualGauge-Bench 提供支持。

DualGauge-Bench

这是一个由 307 个编程任务组成的语言无关基准测试。

任务设计： 每个任务由一段不含代码片段、函数签名或语言特定约束的自然语言规范组成。
配对测试： 每个规范都与源自同一提示词（prompt）的两个测试套件配对：
- 功能测试： 通过边界值分析和等价类划分进行引导，以验证行为正确性。
- 安全测试： 通过 OWASP 和 CERT 原则进行引导，以验证是否存在不安全行为（例如，输入验证失败、访问控制问题）。
覆盖范围： 该基准测试涵盖七个功能领域和 90 个常见弱点枚举（CWE）类别，覆盖了过程内（intraprocedural）和过程间（interprocedural）的任务。
构建方式： 提示词从现有数据集（CodeGuard+、SecurityEval、Purple Llama CyberSecEval）中提取并转换为纯规范。测试套件通过“人-LLM 协同创建”过程创建，即由 LLM 提出候选方案，再由人类评判员进行验证和扩展。

DualGauge 系统

该系统通过四个阶段来自动化评估流水线：

样本生成： 目标 LLM 或智能体针对给定规范生成 $k$ 个代码候选方案。
智能体执行： 一个由 LLM 引导的执行器在隔离环境中运行候选方案。它将失败分类为环境、脚本或代码问题。它会修复环境和脚本问题（例如，缺失包、调用错误），但不会修改候选代码本身。这确保了程序是可执行的，而不会人为地修复模型的逻辑。
基于 LLM 的运行时评估：
- 功能预言机： 使用与预期输出的精确输出匹配。
- 安全预言机： 使用 LLM 进行语义判断。它分析候选代码、执行输出以及针对预期安全行为的覆盖轨迹。如果代码使用了陌生的库，具备网络搜索能力的解析模型会检索文档以辅助评估。这一步旨在确定代码实现的是真正的防御措施，而非仅仅是由于偶然失败而未触发漏洞。
结果聚合： 计算包括功能通过率（$PR $）、安全通过率（$ SPR$）以及联合指标 secure-pass@k（单个样本既功能正确又安全的概率）在内的各项指标。

关键结果

作者评估了 10 个代表性 LLM（包括 GPT-5、Claude Opus/Sonnet、Llama、Qwen 和 Gemma 系列）在 Python、C++ 和 JavaScript 中的表现，以及 3 个智能体编程系统（Codex、OpenHands、Claude Code）。

1. 功能正确性高估了可靠性

即使是最强的模型，在 Python 任务上的功能通过率也仅接近 39%，但在所有语言中，联合安全-功能成功率（secure-pass@1）始终低于 15%。这表明功能正确性是衡量安全代码生成的糟糕代理指标。

2. 模型侧因素并不能可靠地提升联合性能

研究考察了四个因素：规模、扩展思维（extended thinking）、量化以及指令/代码专业化。

规模： 增加模型规模提高了功能流畅度，但安全覆盖率在达到较大规模之前就已进入平台期。
扩展思维与专业化： 这些因素根据模型家族的不同，对功能和安全指标的影响各异，且并未能可靠地提升联合指标。
结论： 安全且正确的代码生成并不简单地从更强的编程能力中涌现；它需要跨所有需求一致地应用安全知识。

3. 智能体系统并无优势

迭代式脚手架（由 Codex、OpenHands、Claude Code 等编程智能体提供）对于仅限规范的任务并不能提供优势。

失败机制： 智能体在面向仓库的开销（例如，列出目录、搜索配置文件）上花费了大量精力，而在空的工作区中这些操作没有任何信号。
反馈循环： 智能体通常依赖于自生成的测试，而非基准测试的地面真值（ground-truth）。那些通过了智能体内部检查但未能通过基准测试安全测试的局部防御措施，并未得到修正。因此，智能体继承了与直接生成相同的失败模式，未能弥合覆盖差距。

4. 失败模式

功能失败： 集中在输出契约边界处（例如，错误的 JSON 结构、错误的 CLI 与服务调用），而非算法错误。
安全失败： 特征是局部防御。模型通常实现了看起来合理的防护措施（正则表达式、类型检查），但未能覆盖特定的攻击向量，或者应用在错误的抽象层级上。
联合差距： 一个程序可能通过功能测试但仍不安全，或者通过了部分安全测试但失败了其他测试。只有联合基准测试才能可靠地暴露这些“沉默”的失败。

重要性与主张

本文声称提出了 首个用于联合评估仅限规范代码生成中安全性与功能性的全自动框架。其重要性在于：

揭示差距： 证明了当前的先进模型和智能体在同时满足正确性和安全性方面存在困难，其联合成功率仍然极低（<15%）。
方法论转向： 认为安全评估需要对执行轨迹进行语义推理，而非仅仅进行输出匹配，并且基准测试必须针对同一规范配对功能测试和安全测试。
智能体局限性： 表明在没有现有代码库或测试运行器来引导智能体的情况下，多轮细化和工具使用目前还无法自动克服生成安全代码的核心挑战。
基准测试标准： 提供了一个语言无关、可重用的基准测试（DualGauge-Bench），它超越了代码补全，旨在测试模型将自然语言意图转化为安全、正确代码的基础能力。

作者总结道，安全的代码生成需要一致地应用安全知识以应对全空间的需求，而目前的模型和智能体尚未掌握这一能力。他们强调，其结果属于可扩展的基准测试估计，人工安全审查仍然是必要的。