💻 computer science

Persistent Human Feedback, LLMs, and Static Analyzers for Secure Code Generation and Vulnerability Detection

本文表明，CodeQL 和 Semgrep 等静态分析工具在与人类验证的 LLM 生成代码真值进行对比时表现出显著差异，从而促使提出了一个旨在通过将持续的人类反馈集成到动态检索增强生成流水线中，以增强安全代码生成和漏洞检测的框架。

原作者： Ehsan Firouzi, Mohammad Ghafari

发布于 2026-02-06

📖 1 分钟阅读☕ 轻松阅读

原作者： Ehsan Firouzi, Mohammad Ghafari

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

想象一下，你正在雇佣一位非常有才华、动作极快但缺乏经验的学徒厨师（即 LLM）来烹饪一道复杂的菜肴。为了确保食物可以安全食用（安全代码），你会要求厨师完成烹饪后，再根据一本规则手册进行检查。

这里是研究人员发现的问题以及他们提议的解决方案，通过简单的类比来讲述。

1. 问题所在：“规则手册” vs. “专家厨师”

在编程世界中，我们有两种主要方式来检查一份食谱是否安全：

规则手册（静态分析器）： 像 CodeQL 和 Semgrep 这样的工具就像是自动化的拼写检查器或营养标签扫描仪。它们扫描代码以寻找已知的危险成分（漏洞）。
专家厨师（人类反馈）： 一个真正的真人会品尝菜肴，理解上下文，并且知道仅仅因为某种成分在标签上看起来很安全，如果混合方式不对，它仍可能是有毒的。

这项研究：
研究人员要求一位 AI 厨师烹饪了 1,080 道不同的菜肴（代码样本），这些菜肴旨在设计为是安全的。然后，他们让一位人类专家对每一道菜进行品尝测试，以建立“真相”。

真相： 61% 的菜肴实际上是安全的。
规则手册的判定：
- Semgrep 说 60% 是安全的。（这在纸面上看起来不错！）
- CodeQL 说 80% 是安全的。（这看起来甚至更好！）

转折点：
当研究人员观察单个菜肴时，规则手册经常出错。

Semreg 在案例中与人类专家的意见一致率仅为 65%。
CodeQL 的一致率仅为 61%。

隐喻：
想象一个保安（工具）在检查进入大楼的人员。

保安可能会因为某人穿着得体而让他进入，从而导致漏掉了危险人物（假阴性/漏报）。
或者，保安可能会因为某人提着一个看起来可疑的包而拦下无辜的人（假阳性/误报）。

论文指出，仅仅依赖保安（静态分析器）是危险的。即使保安得到的“平均数”是对的，他们在处理具体的、关键的案例时仍然会犯错。我们需要人类专家介入。

2. 当前研究中的差距

研究人员查看了数百篇关于 AI 和安全的其他研究。他们发现了一个模式：

语言偏差： 大多数研究仅在 Python（用于烹饪食谱）或 C/C++（用于制造引擎）上测试 AI。它们很少测试其他语言。
工具依赖： 几乎所有人都在使用“规则手册”（静态工具）来给 AI 打分。很少有研究真正让渡给人进行“品尝测试”。
“记忆”问题： 当人类专家抓住一个错误时，他们会针对那一道菜进行修复。但一旦专家离开，AI 就会忘记这个教训。下次 AI 烹饪类似的菜肴时，它会再次犯同样的错误。

3. 解决方案：“智能图书馆”框架

作者提出了一种新的工作方式，称之为 “人类在环”（Human-in-the-Loop, HIL）框架。你可以把它想象成给 AI 厨师配备了一个永不遗忘的 智能图书馆。

以下是新系统的工作原理：

提示词代理（订单接单员）： 当你要求 AI 烹饪时，该代理首先检查智能图书馆。它会询问：“我们以前做过这道菜吗？人类专家对这个特定成分有什么建议吗？”它会将这些建议添加到厨师的指令中。
安全代理（初步品尝）： AI 完成烹饪。安全代理（规则手册）首先对其进行扫描。
人类代理（主厨）： 这是至关重要的一步。人类专家会对安全代理的报告进行审查。
- 如果安全代理说“安全”，但人类说“危险”，人类会进行修复。
- 神奇之处： 人类的反馈不仅仅是一次性的修复。它会被永久存储在智能图书馆中。
信任分数： 并非所有存在于图书馆中的建议都是平等的。
- 如果两位专家对一条建议达成一致，它的“信任分数”就会变高。
- 如果这条建议在过去被成功使用了多次，它的分数就会上升。
- 如果是新建议，它会在“暂存区”等待，直到得到两位专家的认可。这可以防止错误的（或“被投毒的”）建议进入图书馆。

4. 为什么这很重要

论文结论指出，我们不能仅仅依靠自动化工具（规则手册）来告诉我们 AI 生成的代码是否安全。它们在细节上经常出错。

相反，我们需要一个这样的系统：

人类是最终的裁判。
人类的教训会被永久保存。
AI 从过去的专家纠正中学习，这样它就不会再犯同样的错误。

简而言之，AI 很快，工具擅长扫描，但 人类专家才是唯一真正理解上下文的人。通过构建一个能够记住人类专家所言的系统，我们可以让 AI 生成的代码变得更加安全。

技术摘要：用于安全代码生成与漏洞检测的持久化人类反馈、大语言模型（LLMs）及静态分析器

问题陈述
本文探讨了在利用大语言模型（LLMs）进行安全代码生成和漏洞检测的过程中，日益增长的对 LLMs 的依赖，并指出了当前评估方法论中的一个关键缺陷。尽管 LLMs 在软件开发中的应用日益广泛，但即使在明确指示的情况下，它们仍经常生成不安全的代码。现有文献主要将自动化静态分析工具（如 CodeQL、Semgrep）作为唯一的地面真值（ground truth）来评估这些模型。作者认为这种方法存在缺陷，因为静态分析器具有较高的误报率，并且往往无法与人类专家关于实际安全漏洞的判断保持一致。此外，目前的框架缺乏持久化存储和重用专家反馈的机制，限制了 LLMs 从过去的修正中学习的能力。

研究方法
本研究采用了双管齐下的方法论：全面的文献综述和实证验证研究。

文献综述： 作者调查了来自顶级软件工程会议（A/A*）的 2025 年发表的 2025 篇论文，以刻画当前的研究趋势。他们分析了用于安全代码生成和漏洞检测研究的基准测试、目标编程语言、模型系列以及评估工具。
实证验证：
- 数据集构建： 利用递归批判改进（Recursive Critiques Improvement, RCI）提示技术，结合 GPT-4o，作者基于映射到 CWE Top 25 的 108 个独特任务生成了 1,080 个代码样本。
- 地面真值创建： 两名经过培训的评审员（一名博士生和一名硕士生）在教职人员的监督下，手动检查样本，并根据其特定的目标 CWE 将其标记为存在漏洞或安全。通过讨论或专家仲裁解决了分歧，实现了极高的评分者间一致性（Cohen's $\kappa = 0.94$ ）。
- 工具对比： 将手动验证的地面真值与两种广泛使用的静态分析工具——CodeQL 和 Semgrep 的输出进行了对比。
- 框架提议： 基于研究结果，作者提出了一个将人类反馈集成到检索增强生成（RAG）流水线中的概念框架。

关键结果
实证研究揭示了自动化工具与人类专家之间的显著差异：

地面真值： 61% 的生成样本是真正安全的，39% 包含漏洞。
工具性能： Semgrep 将 60% 的样本分类为安全，CodeQL 将 80% 的样本分类为安全。虽然 Semgrep 的总体比例看似接近人类判断，但针对单个样本的分析显示出实质性的分歧。
准确率指标： 仅有 65% 的 Semgrep 报告和 61% 的 CodeQL 报告正确匹配了地面真值标签。
CWE 覆盖率： 两种工具在大量的地面真值案例中都未能检测到目标 CWE，并且经常针对非目标 CWE 报告发现（这些 CWE 的有效性在本研究中仍处于未知状态）。
自我批判： 研究观察到，提供“具体”自我批判（即有针对性、可操作的反馈）的 LLMs 比提供“泛泛”批判（56% 安全）能产生更安全的代码（64% 安全）。

提议的框架：持久化人类反馈
为了解决静态工具的局限性和当前反馈循环的瞬时性问题，作者提出了一个将人类在环（Human-in-the-Loop, HIL）智能体集成到动态 RAG 流水线中的概念框架（如图 3 所示）。该框架由四个智能体组成：

提示词智能体（Prompt Agent）： 通过从双源 RAG（人类反馈和外部漏洞知识）中检索相关的安全指导来编排代码生成，从而优化开发者的提示词。
安全智能体（Security Agent）： 使用静态分析器和 LLMs 评估生成的代码，生成机器可读和人类可读的报告。
人类在环（HIL）智能体： 作为最终决策者。专家审查安全智能体的报告。在出现分歧时，专家反馈会被持久化存储在 RAG 中。
- 信任权重： 系统根据评审共识和历史经验成功率（使用指数移动平均法）为反馈分配动态信任权重。
- 双重评审： 为防止数据中毒，新的反馈在进入活跃检索池之前需要两名不同评审员的批准。
双源 RAG： 一个共享知识服务，通过一个惩罚通用建议与专家反馈之间矛盾的复合评分函数，优先考虑经过人类验证的反馈（HF）而非通用外部知识（EVK）。

意义与主张
本文主张，仅依赖静态分析工具来评估 LLM 生成的代码是不可靠的，并且会对安全研究的有效性构成风险。作者断言，专家反馈不仅对于单个实例是必要的，而且可以推广到未来的类似案例。因此，所提出的框架旨在使 LLMs 能够动态地重用先前的专家反馈，从而提高安全代码生成和漏洞检测的能力。研究结论指出，软件工程界必须超越仅依靠自动化的评估，引入持久的、专家驱动的反馈循环，以确保 LLMs 在安全关键环境中的可靠性。

局限性（有效性威胁）
作者承认存在以下几点局限性：

构念有效性： 文献综述仅限于软件工程领域的 2025 年出版物，可能遗漏了安全领域（如 USENIX Security, CCS）的模式。
内部有效性： 地面真值标签依赖于人工评估，尽管评分者间一致性很高，但仍受人类偏见影响。
外部有效性： 实验侧重于使用 RCI 提示技术的 GPT-4o 生成的 Python 代码。结果可能无法推广到其他语言（特别是 C/C++ 等底层语言）、不同领域或其他 LLMs 及静态分析工具。

1. 问题所在：“规则手册” vs. “专家厨师”

2. 当前研究中的差距

3. 解决方案：“智能图书馆”框架

4. 为什么这很重要

技术摘要：用于安全代码生成与漏洞检测的持久化人类反馈、大语言模型（LLMs）及静态分析器

类似论文