💻 computer science

LLM vs. SAST: A Technical Analysis on Detecting Coding Bugs of GPT4-Advanced Data Analysis

本文通过一项受控研究表明，GPT-4（高级数据分析）在检测 32 种安全场景下的代码漏洞方面显著优于聚合静态应用程序安全测试（SAST）工具（SonarQube 和 Cloud Defence），其检测率达到 93.75%，而后者仅为 34.375%，且具有统计学显著性。

原作者： Madjid G. Tehrani, Eldar Sultanow, William J. Buchanan, Mahkame Houmani, Christel H. Djaha Fodja

发布于 2026-07-15

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Madjid G. Tehrani, Eldar Sultanow, William J. Buchanan, Mahkame Houmani, Christel H. Djaha Fodja

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

想象一下，你是一名正在试图抓捕一名潜伏在计算机程序代码中的狡猾小偷的侦探。多年来，你一直依靠一支机器人检查员团队（被称为 SAST 工具）来扫描代码。这些机器人非常擅长执行严格的清单：“如果你看到红色的门，就标记它。”但有时，小偷会躲在看起来像红色的蓝门后面，或者使用清单所不知道的诡计。机器人会漏掉这些狡猾的把戏，或者会被弄混，把无害的东西误标为危险。

现在，一名新的侦探加入了团队：GPT-4，一个能像读故事一样阅读代码的超级聪明 AI。大的疑问是：这个新的 AI 侦探能否比旧的机器人检查员更敏锐地发现这些棘手的安全漏洞？

伟大的侦探对决

为了找出答案，研究人员设计了一个公平的测试。他们创建了 32 个特定的“犯罪现场”（安全场景），这些场景基于现实世界的编码错误，比如留下后门或让坏人注入虚假命令。他们将这些场景交给了：

机器人团队： 两名不同的机器人检查员（SonarQube 和 Cloud Defence）。它们协同工作，如果其中任何一个机器人发现了问题，就算作机器人的胜利。
AI 侦探： GPT-4，它被要求阅读代码并解释哪里出了问题。

计分板

以下是他们对比结果时发生的情况：

机器人团队： 他们抓住了 32 起犯罪中的 11 起。大约成功率为 34%。
AI 侦探： GPT-4 抓住了 32 起犯罪中的 30 起。其成功率高达 93.75%！

研究人员使用了一种特殊的数学测试（称为 McNemar 检验）来确保这不仅仅是运气。结果是一个明确的“是”：在这项受控实验中，AI 侦探在发现这些特定漏洞方面，在统计学上明显优于机器人团队。

这意味着什么（以及不意味着什么）

论文指出，像 GPT-4 这样的 AI 可以成为机器人检查员强大的搭档。它擅长理解代码背后的“故事”，并能发现那些死板清单所错过的复杂诡计。这可以帮助开发人员更快地修复漏洞，甚至可能节省昂贵工具的费用。

然而，论文非常谨慎地表示，并不意味着机器人已经过时了。

它不是魔杖： AI 并非完美无缺。它漏掉了 32 例中的 2 例，而机器人也抓住了一些 AI 没发现的东西。
它不是替代品： 作者认为我们不应该直接丢弃机器人。相反，我们应该利用 AI 来辅助机器人，特别是针对那些需要类人推理能力的复杂案例。
新的危险： 论文警告说，使用 AI 会带来新的风险。就像小偷可以欺骗机器人一样，坏人也可以欺骗 AI（使用诸如“提示词注入”或在训练数据中隐藏恶意指令等手段）。如果我们不小心，AI 甚至可能会生成看起来安全但实际上漏洞百出的代码。

底线

在这个针对 32 个精心挑选的案例进行的特定测试中，AI 侦探证明了它能看到机器人检查员所忽略的东西。但研究人员表示，这仅仅是个开始。我们需要保持警惕，持续测试，并记住，虽然 AI 是一个出色的新工具，但它还不是一个已解决的问题。它是一个强大的伙伴，但仍然需要人类来拿着手电筒并检查它的工作。

技术摘要：一种用于分析大语言模型（LLM）与静态应用安全测试（SAST）编码缺陷的方法论

问题陈述

本文针对一个关键的网络安全差距提出了研究：即如何量化大语言模型（LLM）在漏洞检测方面的实际有效性，并将其与成熟的静态应用安全测试（SAST）工具进行对比。虽然 SAST 是识别部署前安全缺陷的行业标准，但它经常面临高误报率（将非问题标记为问题）和高漏报率（错过可利用的漏洞）的问题，从而延迟了修复过程并扩大了“漏洞窗口”。相反，尽管像 GPT-4 这样的大语言模型在代码理解方面展现出了潜力，但目前仍缺乏透明且可复现的方法论，来确定它们是否能在受控条件下比传统的 SAST 工具更有效地检测出一系列广泛的现实世界漏洞模式。

方法论

作者提出了一项受控对比研究，旨在评估 GPT-4（具体为高级数据分析接口）与两种 SAST 工具——SonarQube（SonarCloud）和 Cloud Defence 的表现。

数据集： 研究利用了 32 个经过策划的安全场景，这些场景代表了常见的编码陷阱和零日漏洞潜力。这些场景源自 GitHub 和 Snyk，并映射到 MITRE Common Weakness Enumeration (CWE)，涵盖了包括 SQL 注入、缓冲区溢出和容器权限提升在内的多种多样的问题。
实验设计：
- SAST 基准： 将 SonarQube 和 Cloud Defence 的输出通过逻辑 或（OR） 操作进行聚合。如果其中任一工具标记了漏洞，则认为该漏洞已被“SAST 基准”检测到。
- LLM 执行： 每个代码片段都被提交给 GPT-4，并附带固定的指令，要求其识别安全漏洞并解释该问题。
- 评分： 采用二元评分规则。如果工具明确识别了与分配的 CWE 一致的预期漏洞类型，则判定为 1（正确）；否则，判定为 0（漏检）。
统计分析： 鉴于每个代码样本都会产生成对的二元结果（GPT-4 vs. 聚合后的 SAST），作者采用了 McNemar 检验 对配对名义数据进行统计推断。通过构建列联表来对结果进行分类，包括：两者均正确、仅 SAST 正确、仅 LLM 正确以及两者均错误。将 p 值低于 0.05 设定为统计显著性的基准。

关键结果

研究得出了以下定量发现：

检测率： GPT-4 正确检测了 32 个场景中的 30 个（93.75%）。聚合后的 SAST 基准仅检测到了 32 个场景中的 11 个（34.38%）。
差异分析： 配对比较显示出显著的方向性失衡。在 22 个案例 中，GPT-4 检测到了漏洞而 SAST 工具未能检测到（列联表中的 c 单元格）；而 SAST 工具检测到漏洞但 GPT-4 漏检的情况则为 0 个案例（列联表中的 b 单元格）。
统计显著性： McNemar 检验产生的卡方值为 20.046，p 值为 0.000007562。
假设检验： 基于这些结果，在 5% 的显著性水平下，拒绝了原假设（ $H_0$ ：GPT-4 的表现与 SAST 相同或更差），接受了备择假设（ $H_1$ ：GPT-4 的表现优于 SAST）。

核心贡献

本文的主要贡献不在于引入了一种新的漏洞检测器，而在于建立了一套透明、可复现的评估协议，用于比较 LLM 与 SAST 工具。该方法论包括：

一套经过策划的代表性漏洞场景。
一套一致的检测结果二元评分规则。
使用逻辑“或”操作的聚合 SAST 基准。
应用配对统计推断（McNemar 检验）来比较基于相同输入的检测器。

该框架允许进行受控的相对检测能力测量，超越了轶事证据，实现了具有统计学依据的比较。

重要性与主张

作者声称，他们的发现证明了通用大语言模型可以作为传统 SAST 工具在特定漏洞检测任务中的强大补充，甚至可能是替代方案。研究表明，LLM 在识别基于规则的静态分析所遗漏的复杂漏洞机制方面可能特别有效。

然而，论文对于其影响保持了适度且谨慎的态度：

补充作用： 作者明确指出，目标不是取代 SAST，而是表征 LLM 何时具有互补性。SAST 在系统化、基于规则的分析以及 CI/CD 集成方面仍然具有价值。
操作约束： 研究强调 LLM 并非无懈可击。它们依赖于训练数据的模式，并且可能无法检测出在其训练截止日期之后出现的新型漏洞。
安全风险： 论文承认了将 LLM 集成到安全工作流中的安全风险，包括提示词注入、模型窃取以及 LLM 生成不安全代码的可能性。文章倡导使用“设计安全（Secure by Design）”原则、零信任架构以及联邦学习（FL-LLM）来增强韧性。
局限性： 作者指出了局限性，包括受限的场景集（32 个样本）、对测试时特定工具配置的依赖，以及使用的是静态代码片段而非完整的项目或运行时环境。

总之，本文提供了实证证据，表明在受控条件下，GPT-4 在检测特定编码缺陷方面显著优于结合后的 SAST 基准，支持将 LLM 辅助分析集成到安全软件开发生命周期中作为一种补充能力。