🤖 machine learning

An Empirical Study of Security Calibration in Large Language Models for Code

本文提出了首个大规模实证研究，揭示了大语言模型在其生成的代码中普遍存在过度自信现象，其中功能校准的表现始终差于安全性校准，并且尽管校准引导的修复和架构门控能提供有限的益处，但它们往往无法在现实的仓库级上下文中防止高置信度的漏洞。

原作者： Mohammed Latif Siddiq, Md. Nafiu Rahman, Joanna C. S. Santos

发布于 2026-07-01

📖 1 分钟阅读☕ 轻松阅读

原作者： Mohammed Latif Siddiq, Md. Nafiu Rahman, Joanna C. S. Santos

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

想象一下，你有一支非常有才华、但又有点过度自信的初级程序员团队。你要求他们编写代码来保护你的数字家园安全。他们写好了代码，然后带着灿烂的笑容告诉你：“我有 95% 的把握这是安全的！”

这篇论文就像是针对这种场景的一次“现实检查”。研究人员提出了一个问题：这些 AI 程序员真的知道自己什么时候错了，还是仅仅在犯着危险错误时也自信满满地宣称自己是对的？

以下是利用简单类比对研究结果进行的拆解：

1. “自信地犯错”问题

研究发现，这些 AI 模型存在**虚假信任（False Trust）**的问题。

类比： 想象一位天气预报员说：“有 90% 的概率是晴天，”但每次都会下雨。
研究发现： 当 AI 生成带有漏洞（例如为黑客留下的后门）的代码时，它通常会声称自己有 90% 或 95% 的信心认为代码是安全的。实际上，代码往往是不安全的。AI 就像一个开车闯红灯的司机，一边飞速行驶，一边自信地坚持说：“我确定能过去。”

2. “安全 vs. 可用”的意外发现

关于 AI 到底在哪些方面感到困惑，有一个最有趣的发现。

类比： 想象一位厨师。
- 功能正确性（Functional Correctness）： 这道菜味道好吗？是否符合食谱？
- 安全性（Security）： 厨房里是否有毒？
研究发现： AI 在识别其“毒素”（安全缺陷）是否存在方面，实际上比识别其“菜肴”（功能代码）是否正常运作方面表现得更好。
- AI 经常无法意识到自己的代码坏了（无法运行），但它稍微擅长意识到自己是否不小心留下了“毒素”。
- 为什么？ 研究人员认为，“运行”代码取决于一些隐藏且复杂的因素（如特定的软件版本或隐藏设置），而 AI 看不到这些。但“安全”缺陷通常是可见的模式（如使用了已知的危险工具），AI 即使在仍然高估自身技能的情况下，也能更容易地识别出这些模式。

3. “独奏者” vs. “大交响乐团”

研究人员在两种不同的环境中测试了 AI：

环境 A（自包含）： 要求 AI 编写一个单一、孤立的函数（就像一名钢琴独奏家）。
环境 B（仓库级）： 要求 AI 在一个拥有数千个文件和依赖项的庞大、真实的软件项目中修复一个漏洞（就像整个交响乐团共同演奏）。
研究发现： 在“大交响乐团”的环境中，AI 的信心崩溃了。
- 在“独奏”设置下，AI 虽然过度自信，但尚在可控范围内。
- 在“真实世界”设置下，AI 变得极度过度自信。它会声称有 90% 的把握修复成功，但因为它不理解其他文件构成的复杂网络，这个修复往往会破坏整个系统，或者让安全漏洞依然存在。现实世界的复杂性使得 AI 的“信心计分器”完全失去了作用。

4. 我们能“修复”这个 AI 吗？

研究人员尝试利用 AI 自身的信心来修复它的错误。

策略： “如果 AI 说它只有 40% 的把握，那我们就让它再试一次。”
结果： 效果并不理想。
- 类比： 这就像要求一个迷路的司机“再试一次”去导航迷宫。他们往往不是找到了正确的路径，而是直接把车撞到了墙上（破坏了代码的功能）。
- 具体的障碍： 研究发现，某些安全漏洞就像一扇锁着的门，需要一把特定的钥匙（将危险工具替换为安全的工具）。AI 非常不擅长更换这些“钥匙”。它试图在门上贴一个“禁止入内”的告示（添加警告），而不是真正更换锁芯。这被称为“僵化障碍（Rigidity Barrier）”。

5. 如何解决信任问题

论文测试了几种阻止我们盲目信任 AI 的方法：

“守门员”法（最有效）： 在询问 AI“这是否安全？”之前，先问“这段代码能否实际运行？”
- 如果代码无法运行，立即将其丢弃。
- 结果： 这显著减少了 AI 在安全问题上“自信地犯错”的情况。这就像是在询问司机刹车是否灵敏之前，先检查汽车是否有发动机。
“示例”法（效果较差）： 向 AI 展示优秀的代码示例。
- 结果： AI 学习了“优秀代码”的模式，但往往无法将其融入到特定的项目中，从而在过程中破坏了系统。

核心结论

论文得出结论：我们不能将 AI 的“信心得分”视为安全的保证。

AI 通常过度自信，尤其是在处理复杂的现实项目时。
它的信心是判断代码是否真正安全的糟糕指标。
最好的方法是将 AI 的输出视为一份草稿，必须由人类或自动化工具进行严格的测试（检查错误和安全缺陷），而不是仅仅因为它说“我确定这是对的”就全盘接受。

简而言之：不要被 AI 的自信所迷惑。即使它听起来很笃定，它也可能出错。

技术摘要：大规模语言模型代码安全校准的实证研究

1. 问题陈述

大语言模型（LLMs）正越来越多地集成到软件开发工作流中，用于代码生成和漏洞修复等任务。然而，将其部署在安全关键型场景中引发了一个根本性问题：模型是否准确地知道其生成的代码是不安全的？

虽然现有的基准测试（如 HumanEval、MBPP、SWE-Bench）评估了功能正确性，但它们很大程度上忽略了安全属性。近期的面向安全的基准测试评估了代码是否包含漏洞，但未能衡量模型是否能够自我评估其输出的安全性。这一差距导致了**错误信任（False Trust）**现象，即模型会对存在漏洞的代码赋予高置信度。依赖这些置信度信号的开发者可能会在不经审查的情况下接受不安全的输出，从而将漏洞传播到生产系统中。

此前的研究尚未系统地测量安全校准（security calibration）——即模型对输出安全性的陈述置信度与其输出实际安全状态之间的对齐程度。此外，目前尚不清楚在孤立、自包含程序中观察到的校准模式是否能推广到现实的、多文件仓库上下文中，或者校准信号是否能有效地指导自动化漏洞修复。

2. 研究方法

作者提出了首个大规模安全校准实证研究，评估了三种最先进的模型：GPT-4o-mini、Gemini-2.0-Flash 和 Qwen3-Coder-Next。该研究通过两个互补的基准测试和四个研究问题（RQ）进行多阶段评估。

数据集与上下文

自包含程序 (RQ1)： 使用了 SALLM 基准测试，包含 100 个安全关键型 Python 任务。每个任务提供一个包含输入、预期输出和安全要求的单一提示词，且与外部依赖项隔离。
仓库级上下文 (RQ2)： 使用了 AICGSecEval 基准测试，涵盖四种语言（C、Java、PHP、Python）和 29 种 CWE。这些任务要求在现有的多文件仓库中生成补丁，涉及跨文件依赖、构建配置和外部 API。

实验设置

模型与参数： 每个模型在六种温度设置（0.0 到 1.0）下进行测试，每个任务生成 20 个样本。
置信度估计： 对比了四种方法：
1. Token 概率聚合： 直接访问 Logit 概率（针对 GPT/Gemini）。
2. 口头表达置信度： 通过提示模型输出包含置信度分数（0–1）和推理过程的 JSON。
3. 基于采样的一致性： 将置信度估计为 20 个样本中通过验证的比例。
4. 自一致性提示： 在报告置信度之前进行思维链（CoT）推理。
验证： 代码在隔离的 Docker 容器中执行。安全标签定义为 $y_{sec} = y_{func} \land \neg y_{vuln}$ ，即代码必须通过所有功能测试并失败所有漏洞利用测试，才被视为安全。
指标： 期望校准误差（ECE）、Brier 分数、过度自信差距（Overconfidence Gap）以及错误信任（FT）率（高置信度但实际不安全的预测）。

修复与缓解策略 (RQ3 & RQ4)

校准引导修复： 一个闭环系统，对低校准置信度（ $p_{sec} < 0.5$ ）的样本进行过滤以进行迭代修复。结果按漏洞类型进行分类：汇聚点替换（Sink Replacement, SR）（需要 API 变更）和 约束强制（Constraint Enforcement, CE）（需要验证逻辑）。
缓解实验：
1. 执行门控（Execution Gating）： 在询问安全性置信度之前，先过滤掉功能错误的代。
2. 授权破坏性修复（Authorized-Breaking Repair）： 明确授权模型破坏向后兼容性（例如，将 pickle 替换为 json）以修复 SR 漏洞。
3. 少样本提示（Few-Shot Prompting）： 提供安全代码示例。
4. 少样本 + CoT： 在少样本示例中加入推理步骤。

3. 关键结果

RQ1：自包含生成的校准情况

系统性过度自信： 所有模型都表现出严重的过度自信。GPT-4o-mini 和 Qwen3-Coder-Next 的 ECE 较高（分别为 0.46–0.48 和 0.41–0.42），而 Gemini-2.0-Flash 表现较好但仍存在过度自信（ECE 0.25–0.26）。
错误信任： 在 0.8 的置信度阈值下，错误信任率高得惊人（例如，GPT-4o-mini 为 33.5%，Qwen3-Coder-Next 为 40.3%），表明高置信度输出经常是不安全的。
功能性 vs. 安全性校准： 出乎意料的是，功能性校准的表现始终差于安全性校准（ $\Delta ECE < 0$ ）。模型在功能正确性方面的误校准程度高于安全性。这表明模型对安全结果的估计比对功能结果的估计更可靠，可能是因为功能正确性取决于复杂的、隐藏的执行行为。
置信度方法： Token 概率聚合的校准效果很差（ECE $\approx$ 0.80）。基于采样的一致性显示 ECE 接近于零，但缺乏单样本辨别力。口头表达的置信度是下游分析中最实用的信号。

RQ2：仓库级上下文中的退化

校准崩溃： 从自包含任务转向仓库级上下文会导致校准显著恶化。ECE 大约增加三到四倍（例如，GPT-4o-mini 的 ECE 从 0.41 上升到 0.70）。
错误信任激增： 错误信任率从自包含任务中的 ~17% 跳升至仓库设置中的 >80%。
分解分析： 退化由两个因素驱动：构建脆弱性（代码无法编译/运行）和跨文件复杂性。构建脆弱性解释了大部分误差（对于 GPT 高达 82%），但即使在成功构建补丁的情况下，真实的跨文件复杂性仍然是一个重要因素。

RQ3：校准引导修复

功效有限： 使用校准信号来引导修复带来的安全性提升微乎其微，且往往会降低功能性。
结构性障碍： 汇聚点替换（SR） 漏洞（需要更换 API）在所有模型中的修复成功率为 0%。模型无法替换不安全的 API，而是保留漏洞或引入肤浅的修复。
功能回归： 修复尝试经常破坏功能正确性（破坏率 >60%），导致整体安全率下降。校准可以作为风险分层信号，但无法驱动有效的自动化结构性漏洞修复。

RQ4：缓解策略

执行门控： 最有效的缓解措施。在请求安全性置信度之前过滤掉功能错误的代，使各模型的 ECE 降低了 31–39%。然而，这以丢弃 46–86% 的样本为代价。
授权破坏性修复： 明确授权 API 变更提高了 GPT 和 Gemini 移除漏洞的能力（35–42%），但仍会导致较高的功能破坏率和较低的严格成功率。
提示技术： 少样本提示移除了约 61–65% 的漏洞，但很少能通过严格的测试套件，由于结构集成不匹配的问题。添加思维链（CoT）推理反而会降低校准效果，并将严格成功率降至 0%。

4. 核心贡献

首个大规模研究： 首个对 LLM 生成代码进行安全性校准的实证调查，涵盖了三个模型、六种温度、两种不同开发上下文下的 36,000 个样本。
校准退化分析： 量化了从孤立函数转向现实仓库级上下文时所遭受的严重校准惩罚，强调了跨文件依赖带来的风险。
因此，本研究量化了从孤立函数转向现实仓库级上下文时所遭受的严重校准惩罚，突出了跨文件依赖的风险。
修复局限性： 证明了校准引导的修复是不可靠的，特别是对于汇聚点替换（Sink Replacement）类漏洞，这归因于模型无法进行必要的结构性转换。
缓解方案评估： 系统评估了架构级（执行门控）和提示级干预，确定执行门控是降低错误信任最有效的策略，尽管其拒绝成本很高。

5. 重要性与主张

本文认为，校准（而非仅仅是准确性）必须成为 LLM 在安全关键环境下评估的核心标准。研究结果挑战了“安全性对 LLM 而言更难”的假设；相反，研究表明功能性校准比安全性校准更差，这暗示误校准主要源于隐藏的运行时约束（执行脆弱性），而非缺乏安全知识。

作者主张：

自我报告的置信度是不可靠的： 高置信度输出经常是不安全的，这造成了系统性的“错误信任”风险。
上下文至关重要： 基于自包含程序的基准测试显著低估了部署风险，因为在仓库级设置中，校准度会大幅下降。
修复并非万灵药： 校准信号可以优先处理需要人工审查的样本，但目前无法驱动可靠的自动化结构性漏洞修复。
从业者指南： 安全评估应仅在功能测试（执行门控）之后进行，且应分别获取安全性与功能性的置信度信号，以避免受到执行不确定性的干扰。

研究结论指出，虽然 LLMs 显示出一定的自我评估安全性能力，但其过度自信以及无法进行结构性修复的缺陷，使得人类监督在复杂的多文件开发环境中显得尤于必要。