TOSSS: a CVE-based Software Security Benchmark for Large Language Models

本文介绍了 TOSSS（基于 CVE 的双选项安全片段选择）基准，旨在通过让大语言模型在安全与易受攻击的代码片段间进行选择来评估其软件安全能力，该基准具有可扩展性，并在 14 个主流模型上进行了 C/C++ 和 Java 代码的测试。

要点

这篇论文介绍了一个名为 TOSSS 的新工具，用来测试大型人工智能（LLM）在写代码时是否“懂安全”。

为了让你轻松理解，我们可以把这篇论文的核心内容想象成一场**“找茬游戏”和“安全体检”**。

1. 背景：AI 是个天才，但也是个“粗心鬼”

现在的 AI（比如 GitHub Copilot 或各种聊天机器人）非常聪明，能帮程序员写代码。就像请了一位超级速记员，你让它写个功能，它秒回。
但是，这个速记员有个大问题：它经常为了“快”而忽略“安全”。
研究发现，AI 生成的代码里，有相当一部分藏着“后门”或漏洞。如果黑客利用这些漏洞，公司的数据就可能被偷走。所以，我们需要知道：到底哪个 AI 最靠谱？哪个 AI 最容易把代码写“坏”？

2. 旧方法的痛点：像“开卷考试”但题目太死板

以前，人们测试 AI 的安全能力，通常是给 AI 出一道题（比如：“写一个登录功能”），然后让 AI 写代码，再用专门的“安检仪”（静态分析工具）去检查代码有没有漏洞。
这就像： 老师给 AI 出作文题，然后拿着一本固定的《错别字大全》去批改。
缺点：

• 题目太旧： 如果出了新的黑客攻击手法（新漏洞），那本《错别字大全》里没有，AI 就算写错了也查不出来。
• 更新太慢： 每次加新题目，都要人工重新设计，太累了。

3. 新方法 TOSSS：玩“二选一”的找茬游戏

这篇论文提出的 TOSSS benchmark（基准测试），换了一种更聪明的玩法。它不再让 AI 从头写代码，而是玩一个**“找不同”**的游戏。

游戏规则是这样的：

1. 研究人员从真实的黑客攻击记录（CVE 数据库）里，找到一段**“有漏洞的代码”**（比如：一个没锁好的门）。
2. 然后找到这段代码**“修复后的安全版本”**（比如：同一扇门，但加了锁）。
3. 把这两个版本（A 和 B）同时扔给 AI，问它：“这两个版本里，哪个更安全？请只回答 A 或 B。”

这就像：
你给 AI 看两把锁，一把是生锈易断的（漏洞版），一把是崭新的防盗锁（安全版）。你问 AI：“哪把锁更安全？”

• 如果 AI 总是选防盗锁，说明它懂安全（得分高）。
• 如果 AI 总是选生锈的锁，说明它不仅不懂，还偏爱危险（得分低）。

4. 为什么这个方法很厉害？（四大优势）

• 无限更新（扩展性）： 只要黑客发现新漏洞，数据库里一更新，TOSSS 就能自动抓取新的“生锈锁”和“新锁”给 AI 做测试。不需要人工重新出题。
• 简单直接（可扩展性）： 不需要复杂的代码生成，只需要 AI 做选择题，测试速度极快，可以一次测几千道题。
• 结果清晰（可解释性）： 分数就是它选对“安全锁”的概率。
  • 1 分 = 次次选对，安全大师。
  • 0.5 分 = 瞎蒙，跟扔硬币没区别。
  • 低于 0.5 分 = 甚至有点“坏”，专门选有漏洞的。
• 公平性： 以前 AI 可能会因为格式问题（比如多写了个空格）被误判，现在只让它选 A 或 B，完全避免了这种干扰。

5. 实验结果：AI 们表现如何？

研究人员找了 14 个最火的 AI 模型（包括闭源的如 GPT 系列，开源的如 LLaMA 等），用 C/C++ 和 Java 两种语言进行了测试。

• 整体表现： 大部分 AI 都能认出哪个更安全，分数在 0.48 到 0.89 之间。
  • 高分选手： 像 GLM-5、GPT-5.4 等，表现很好，几乎次次选对。
  • 低分选手： 有个叫 Mistral 的模型，分数只有 0.48，基本等于在瞎猜，甚至有点“偏爱”有漏洞的代码。
• 一个有趣的现象（提示词的作用）：
  • 如果不告诉 AI 这是考“安全”，它表现一般。
  • 如果明确告诉它：“请选出最安全的那个”，大部分 AI 的分数都会上涨。
  • 例外： 有个专门写代码的模型（Codestral），一旦你提醒它“要注意安全”，它反而变差了。这说明它可能太专注于“把代码写通顺”，反而被“安全”这个指令搞晕了。
• 结论： 并不是所有“写代码专用”的 AI 都最懂安全。有时候，通用的 AI 反而更谨慎。

6. 总结：这对我们意味着什么？

这篇论文告诉我们：

1. AI 不是万能的： 即使是顶级的 AI，在代码安全上也可能“翻车”。
2. 需要新标准： 以前那种让 AI“写代码”来测试安全的方法太慢了，TOSSS 这种“二选一”的方法更灵活、更真实。
3. 未来方向： 开发者在使用 AI 助手时，应该明确提示它“要注意安全”，这能帮它发挥得更好。同时，AI 公司也应该把这种“安全评分”像“智商分”一样公开，让大家知道谁更安全。

一句话总结：
TOSSS 就像给 AI 发了一张**“安全驾照考试卷”，不再让它现场造车（写代码），而是让它从两辆车里挑出一辆没安全隐患的**。这样既能快速测试谁最靠谱，又能随着新漏洞的出现随时更新考题，确保 AI 不会把我们的代码带进沟里。

技术摘要

这是一份关于论文《TOSSS: a CVE-based Software Security Benchmark for Large Language Models》（TOSSS：一种基于 CVE 的大语言模型软件安全基准）的详细技术总结。

1. 研究背景与问题 (Problem)

随着大语言模型（LLM）在软件工程领域的广泛应用，它们已成为代码生成、补全和修复的重要工具。然而，LLM 生成的代码可能存在严重的安全漏洞。例如，早期研究发现 GitHub Copilot 生成的代码中有 40% 包含安全漏洞。

现有的 LLM 安全基准测试存在以下关键局限性：

• 可扩展性差：大多数基准依赖固定的任务集和静态分析器（如 CodeQL）。当新的漏洞被发现或需要支持新编程语言时，更新基准需要大量人工干预或重新配置分析器。
• 缺乏明确的“真值”对比：传统的代码生成任务难以将模型输出与预定义的参考实现进行精确匹配，通常依赖外部工具近似评估，缺乏明确的对错标准。
• 评估偏差：部分基准依赖人工验证（不可扩展）或 LLM 自身作为裁判（存在逻辑循环），且难以覆盖复杂的、新披露的漏洞。

核心问题：如何构建一个可扩展、自动化、且基于明确真值的基准，以准确评估 LLM 在面对新披露漏洞时的软件安全能力？

2. 方法论 (Methodology)

作者提出了 TOSSS（Two-Option Secure Snippet Selection，双选项安全片段选择）基准，采用了一种与现有基准截然不同的评估策略。

核心设计

• 任务形式：不再是让 LLM 从零生成代码，而是让模型在两个代码片段中进行选择。
  • 选项 A：一个函数的实现版本。
  • 选项 B：同一函数的另一个实现版本。
  • 真值：其中一个版本是易受攻击的（Vulnerable），另一个是修复后的安全版本（Secure）。
• 评估指标：模型选择安全片段的比率（0 到 1 之间）。
  • 1.0：总是选择安全代码。
  • 0.5：随机猜测水平。
  • < 0.5：倾向于选择易受攻击的代码（可能存在恶意行为或严重缺陷）。
• 提示词设置：
  • 无提示（Hintless）：不告知模型任务与安全相关，仅要求选择“更喜欢的版本”。
  • 有提示（With Hint）：明确告知模型“选择最安全的实现”。

测试用例构建（自动化流水线）

为了确保持续的可扩展性，TOSSS 不依赖人工构建数据集，而是利用 CVE 数据库 和 MegaVul 工具：

1. 数据源：MegaVul 是一个自动化管道，用于从 CVE 数据库中挖掘漏洞信息。
2. 提取过程：自动提取 CVE 修复前后的源代码片段（即“修复前”为易受攻击版本，“修复后”为安全版本）。
3. 配对：将同一函数的修复前后版本配对，形成测试用例。
4. 优势：随着新 CVE 的披露，基准可以自动集成新的漏洞类型和编程语言，无需人工重新编写测试用例。

3. 主要贡献 (Key Contributions)

1. 提出 TOSSS 基准：首个基于“代码选择”而非“代码生成”的 LLM 安全基准，解决了传统基准难以扩展和缺乏明确真值的问题。
2. 基于 CVE 的自动化构建：利用 MegaVul 管道从 CVE 数据库自动构建测试集，实现了基准的持续可扩展性（Extensibility），能够轻松纳入新漏洞和新语言。
3. 明确的评估指标：定义了直观的概率性评分（0-1），直接反映模型区分安全与不安全代码的能力，比 pass@k 等指标更易解释。
4. 大规模实证研究：在 14 个主流开源和闭源模型（包括 GPT-5, Claude, LLaMA, Gemini 等）上进行了评估，涵盖 C/C++ 和 Java。
5. 开源发布：公开了基准代码和工具，促进社区复现和后续研究。

4. 实验结果 (Results)

研究评估了 14 个模型在 500 个 C/C++ 函数和 500 个 Java 函数上的表现：

• 整体表现：

  • 在无提示（Hintless）设置下，得分范围从 0.48 (Mistral Large 2512) 到 0.88 (GLM-5)。
  • 大多数模型得分高于 0.5，表明它们在一定程度上具备区分安全代码的能力，但差异巨大。
  • 最佳模型：GLM-5 (0.878), GPT-5.4 (0.866), Claude Opus 4.6 (0.864)。
  • 最差模型：Mistral Large 2512 (0.480)，其表现接近随机猜测。

• 提示词的影响（Hint vs. Hintless）：

  • 明确提示“选择最安全的实现”通常能提升模型表现（平均提升约 +0.02 到 +0.03）。
  • 例外情况：Codestral 2508（专为编码优化的模型）在获得安全提示后，性能反而下降（C/C++ 下降 0.072）。这表明过度强调安全指令可能会干扰某些专注于代码生成流畅性的模型的决策过程。

• 模型类型与语言差异：

  • 专用编码模型：Qwen3 Coder Next 和 Codestral 2508 在无提示设置下排名靠后。这说明针对代码生成优化的模型，并不一定擅长识别或选择安全代码。
  • 语言差异：C/C++ 和 Java 的平均得分相近（无提示下分别为 0.756 和 0.740），表明模型具备跨语言的安全推理能力，而非仅仅记忆特定语言的漏洞模式。
  • 模型迭代：同一家族的新版本模型（如 Claude 3.5 -> 4.6）通常表现出更强的安全能力。

5. 意义与讨论 (Significance)

• 重新定义评估范式：TOSSS 证明了将复杂的“代码生成”问题简化为“代码选择”问题是可行的。如果模型无法在两个选项中识别出安全代码，那么它生成安全代码的能力也值得怀疑。这为评估提供了一个更稳健、可扩展的“最小必要条件”。
• 可扩展性与未来性：基于 CVE 的构建方式使得基准能够随着网络安全威胁的演变而自动更新，解决了传统基准滞后于新漏洞发现的问题。
• 对 LLM 开发的启示：
  • 训练数据：需要过滤训练数据中的已知漏洞代码，或引入基于 CVE 的修复对进行微调。
  • 提示工程：在编码助手中显式加入安全指令通常能提升安全性，但需注意对特定优化模型的潜在负面影响。
  • 基准互补：TOSSS 不应完全取代基于生成的基准，而是作为补充，提供更清晰的安全能力画像。

总结：TOSSS 通过利用 CVE 数据库构建自动化的“二选一”测试任务，为 LLM 的软件安全能力评估提供了一个可扩展、可解释且基于真值的新标准。实验表明，尽管部分模型表现优异，但仍有大量模型（包括一些专用编码模型）在识别安全代码方面存在显著缺陷，且显式的安全指令对提升性能至关重要。