一项 2025 年的基准测试在十个真实的 C# 项目中植入了六十三个真实漏洞，并针对这些漏洞运行了三款行业静态分析工具（SonarQube、CodeQL 和 Snyk Code）。其中表现最好的 Snyk Code 最终 F1 分数约为 0.55。表现最差的 SonarQube 得分为 0.26。随后，同一批研究人员使用三款前沿大型语言模型运行了相同的测试集。GPT-4.1、Mistral Large 和 DeepSeek V3 的得分均在 0.75 到 0.80 之间，这主要得益于它们捕捉到了那些静态分析工具直接忽略的问题。
如果你将此解读为“人工智能获胜，取代静态应用程序安全测试（SAST）”，那你就错了。同一项研究以及大量类似研究表明，大型语言模型在召回率方面胜出（它们能捕捉到更多问题），但在精确率方面表现糟糕。另一项针对不安全的直接对象引用（IDOR）检测的分析发现，某流行的人工智能编程助手标记为 IDOR 的问题中，有 88% 实际上并非 IDOR。因此，你可以让人工智能审查一个包含五十个文件的拉取请求，它确实会找出你遗漏的 SQL 注入漏洞。但它同时也会找出六个并非注入漏洞的注入错误、两个并非竞态条件的竞态条件，以及在根本没有授权机制的代码中标记出的“潜在授权绕过”问题。
这种张力正是人工智能安全审查的本质。你是用一个自信地遗漏问题的审查者，换成了一个自信地发现问题的审查者——包括那些根本不存在的问题。本文旨在探讨这种权衡在四类经典漏洞（SQL 注入、跨站脚本攻击、身份验证漏洞、不安全的反序列化）中何时能带来回报，以及如何将人工智能集成到安全审查流程中，以免噪声淹没信号。
“人工智能安全审查”的真正含义
让我们先剔除营销辞令。当人们提到用于安全审查的人工智能时，他们通常描述的是以下三种情况之一，且这三者不可互换。
第一种是聊天式审查。你将一个函数或代码差异粘贴到模型中，并要求它查找安全问题。这是大多数工程师日常实际采用的方式。它成本低廉，无需基础设施，且对你的代码库没有任何记忆。模型只能看到你粘贴的内容，别无其他。
第二种是代理式审查，它拥有工具（文件读取、grep 搜索，有时包括 shell 执行）以及指示其扫描特定漏洞类别的系统提示词。Claude Code 的安全审查、Gemini CLI Action 以及 GitHub Copilot Agent 的安全模式均属于此类。代理决定查看什么内容；提示词决定什么算作发现的问题。
第三种是混合流水线。确定性的静态分析工具首先找到候选位置，然后针对每个候选位置调用大型语言模型进行分流处理。Semgrep 的人工智能助手就是这样工作的。较新的学术框架（如 SAST-Genius）也是如此。大型语言模型从未见过原始代码库；它看到的只是一个候选发现问题及其周围上下文。
这三种方式从外部看起来相似，但在实际表现上却大相径庭。纯聊天式审查具有高噪声、高灵活性、无记忆的特点。代理式审查噪声中等，范围局限于代理选择查看的内容。混合式审查噪声较低，因为静态应用程序安全测试已经完成了繁重的工作，而大型语言模型只是被询问“这真的可利用吗？”。当有人说“我们使用人工智能进行安全审查”时，在你对结果得出任何结论之前，先弄清楚他们指的是这三种中的哪一种。
人工智能如何“看待”漏洞：简要幕后解析
像 CodeQL 这样的静态分析器正在进行污点分析。它构建程序的数据流图，将来自源（HTTP 查询参数、请求体、环境变量）的任何输入标记为受污点影响，然后通过赋值、函数调用和字段访问追踪该污点，以查看其是否到达汇点（SQL 查询字符串、HTML 模板、反序列化
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
