使用 Claude Code 和 OpenAI Codex 发现现代 Web 应用中的漏洞 | Semgrep
来源 (中文翻译版): https://semgrep.dev/blog/2025/finding-vulnerabilities-in-modern-web-apps-using-claude-code-and-openai-codex/ 抓取时间: 2026-07-21 16:28:02
内容摘要： 我们评估了 AI 编程智能体在真实代码中发现漏洞的有效性。
- 方法：我们让 Anthropic 的 Claude Code（v1.0.32，Sonnet 4）和 OpenAI Codex（v0.2.0，o4-mini）在 11 个流行的大型开源 Python Web 应用程序中寻找漏洞。它们总共产生了 400 多个安全发现，我们的安全研究团队对其进行了审查。
- AI 编程智能体发现了真实漏洞：Claude Code 发现了 46 个漏洞（14% 真阳性率 – TPR，86% 假阳性率 – FPR），Codex 报告了 21 个漏洞（18% TPR，82% FPR）。其中约 20 个是高严重性漏洞。
- AI 掌握上下文，但在流程上遇到困难：Claude Code 在发现不安全直接对象引用（IDOR）漏洞方面表现最好，真阳性率（TPR）为 22%（报告 59 个，正确 13 个），但在跨多个文件和函数执行污点跟踪方面遇到困难，SQL 注入的 TPR 为 5%（2/38），XSS 为 16%（12/74）。
OpenAI Codex 难以报告任何正确的 IDOR，TPR 为 0%（0/5），在 SQL 注入 0%（0/5）和 XSS 0%（0/28）方面表现非常差，但令人惊讶的是，报告的正确路径遍历问题比 Claude Code 更多，TPR 为 47%（8/17）。
- 非确定性是一个真正的挑战：在完全相同的代码库上多次运行完全相同的提示通常会产生截然不同的结果。在一个应用程序中，三次相同的运行分别产生了 3、6 和 11 个不同的发现。
关键要点：
- 具有相对简单的以安全为重点的提示的 AI 编程智能体已经可以在真实应用程序中发现真实漏洞。
- 但是：根据漏洞类别的不同，结果可能会非常嘈杂（高假阳性率），特别是在传统注入式漏洞类别上，如 SQL 注入、XSS 和 SSRF。
- 详细的评估和基准测试是关键，用于了解一种方法在发现漏洞方面的有效性（这一直都是正确的，但对于像大语言模型这样的非确定性工具来说更是如此），以及知道你的改进是否朝着正确的方向前进。
- 这是我们关于使用和增强 AI 来发现漏洞的系列文章的第一篇！
在这篇文章中，我们将涵盖：
- 常见 SAST 基准测试的问题以及它如何影响 AI SAST 评估
- 关于基于 AI 的漏洞狩猎的一些开放研究问题
- 我们的 AI 编程智能体实验、数据集以及我们学到的东西
- Anthropic 的
/security-review命令如何相当一般 - AI 编程智能体的非确定性，以及为什么会发生这种情况
本文最后编辑于 2025 年 9 月 3 日，UTC 时间上午 11:15
- 2025 年 9 月 3 日，UTC 时间上午 11:15：添加了有关使用的模型和调用它们的命令的详细信息
简介
在 Semgrep，我们专注于应用程序安全（AppSec）。我们长期以来一直在产品中生产化 AI（Assistant 背后的技术、用于测试我们 AI 工作流的 promptfoo、使用安全研究员分类来评估自动分类性能），不断研究传统、确定性分析与现代 AI 的上下文能力的最佳结合，而不追逐趋势。 这项研究是这一持续使命的一部分。我们正在开始深入、公开的探索，以回答每个人心中的一个问题：大语言模型在源代码中发现漏洞到底有多有效？
关于基于 AI 的漏洞狩猎的开放研究问题
为了指导我们的调查，我们将"大语言模型擅长发现 bug 吗？"这个广泛问题分解为更具体、可衡量的子问题。
- 基于大语言模型的漏洞发现的假阳性和假阴性率是多少？它是否因编程语言、框架、代码库大小或漏洞类别而异？对代码编写方式的敏感性如何？
- 假阳性和假阴性的常见原因是什么？
- 分析的确定性如何？每次都能得到相同的结果吗？
对于注入漏洞，我们特别想知道：
- 大语言模型在跟踪源（例如用户提供的值）和汇（例如执行原始 SQL 查询的方法）之间的用户输入方面有多有效？
- 它能跨函数和文件跟踪数据吗？
- 它能推理清理函数和其他安全控制吗？
- 它能推理来自第三方开源依赖的函数吗？
常见 SAST 基准测试的问题：缺乏现实性
在深入研究我们的发现之前，让我们谈谈如何衡量 AI 性能。当前的许多研究/主张依赖于基准测试，虽然有价值，但并未完全捕捉现实世界代码的复杂性。
- 具有已知漏洞的应用程序：这些基准测试仅使用具有已知漏洞的开源应用程序；许多可以在 vulnerable-apps 中找到，感谢 Kinnaird McQuade。如果你阅读这篇博客，你可能会认出一些名字 WebGoat、JuiceShop、OWASP Benchmark 等。但是，这些存在一个问题，当前的大语言模型可能已经摄取了这些存储库的代码以及互联网上的许多公开文章，给它们提供了预先存在的知识并扭曲了结果。
它们的代码通常不现实，有大量的注释、注解和变量名，这些要么暗示要么直接描述代码中的漏洞在哪里或如何利用它们。有时，工具结果甚至被检入到代码库中。
来自javaspringvulny 的 SearchService.java
来自juiceshop，挑战是文件名的一部分……
- XBOW 为自动渗透测试工具提供基准测试，但不适应静态分析：代码通常太刻意和简单化，不代表真实应用程序。ZeroPath 在清理它们方面做得很好，但只有一小部分被清理了。此外，这些测试用例中的每一个都是微型应用程序，旨在激发专用的攻击场景。如果我们关注 Python 基准测试，XBOW 有 45 个；45 个不同的微型应用程序，平均不到 98 行代码和 3 个 Python 文件。这太小了，无法捕捉在整个代码库或许多函数中搜索和推理的复杂性。
- CVE 记忆偏差： 由于大语言模型是在来自互联网的大量公共数据语料库上训练的，包括发现和修复 CVE 的相同代码库。这造成了一个根本的数据污染问题。AI 可能不是通过新颖分析来_检测_漏洞，而只是_识别_它在训练期间记忆的模式。
最近，学术界设计了基准测试，如CyberGym、Eyeballvul 或 SecVulEval。这些显示了巨大的改进，更接近现实世界的例子，但它们缺乏对现代 Web 应用的关注，或者将漏洞从更广泛的应用程序上下文中隔离出来。
- EyeballVul： 来自 Timothée Chauvin 的更新基准测试，从开源项目中提取真实世界、人类审查的漏洞，并将其呈现为最小的、可重现的测试用例。虽然基于真实代码，它仍然将漏洞从更广泛的应用程序上下文中隔离，使搜索问题变得更容易。
- SecVulEval 和 CyberGym： 这些套件旨在评估 C 或 C++ 中的漏洞。虽然在其领域有价值，但它们对 C 和 C++ 的关注意味着这些数据不适用于主导现代云原生开发的 Python/JavaScript 和其他以 Web 为中心的语言。
虽然这些方法中的每一种都很有用，有时应该使用，但它们不一定反映现代软件开发的现实。现实世界的应用程序不是干净、孤立的函数。它们是依赖项、框架和业务逻辑的复杂网络。 我们的方法不同。我们在11 个大型、基于 Python、积极维护的开源项目上进行了测试，这些项目用常见的 Web 框架（Django、Flask、FastAPI）编写。我们的方法是对以前方法的补充，我们相信它的独特之处在于 a) 旨在代表现实世界中 AI 驱动的漏洞发现（与小的、孤立的合成示例相比），b) 不受模型训练数据的污染，以及 c) 代表大多数开发人员和公司实际构建的应用程序类型——使用现代语言和框架的 Web 应用程序。
这篇博客文章的范围
为了使这易于处理，我们专注于：
- 使用开箱即用的 Anthropic Claude Code（v1.0.32，Sonnet 4）和 OpenAI Codex（v0.2.0，o4-mini）的 1 次运行，使用简单的、脚本化的提示 [1]，重用用于不同类型的漏洞。我们要求它们返回 SARIF 格式的 安全问题。
- 分析 11 个不同的大型、现实世界的开源 Python 项目。
- 专注于常见的、高影响的漏洞类别：认证绕过、IDOR、路径遍历、SQL 注入、SSRF 和 XSS。
- 使用 Anthropic 最近的
/security-review命令的探索性结果 - 通过对 3 个不同的应用程序进行 3 次运行，探索这些应用程序子集的（非）确定性以进行 IDOR 研究。
为了奠定我们的研究基础，我们选择了流行且积极维护的项目。以下是我们分析的应用程序规模的一瞥。请注意，我们今天不会发布这些流行开源 Web 应用程序的名称，因为我们仍在进行负责任的披露过程，一旦过程结束，我们将发布数据集。 应用 ID| 提交次数 截至 2025 年 8 月| GitHub 星标| Python 文件| Python 代码行数 无空行。无注释。 ---|---|---|---|--- PY-APP-001| >25k| 5k| >500| 85k PY-APP-002| >5k| 6k| >500| 60k PY-APP-003| >15k| 10k| >200| 45k PY-APP-004| >5k| >100| >500| 95k PY-APP-005| >15k| 1k| >500| 100k PY-APP-006| >25k| 2k| >1000| 110k PY-APP-007| >5k| 20k| >1000| 250k PY-APP-008| >1k| >100| >200| 40k PY-APP-009| 1k| 3k| >50| 2k PY-APP-010| 15k| 5k| >200| 45k PY-APP-011| >5k| >25k| >200| 30k | | | 7k 文件| >800k 代码行 应用程序名称将在所有漏洞披露和处理后发布。
实验：AI 与现实世界应用代码的对抗
我们在 11 个应用程序中运行了我们的分析，然后手动分类了 445 个发现中的每一个，动态验证了其中的大多数（特别是 IDOR 或认证绕过）。
Anthropic Claude Code（v1.0.32，Sonnet 4）
| 漏洞类别 | 真阳性 | 假阳性 | 真阳性率 |
|---|---|---|---|
| 认证绕过 | 6 | 52 | 10%（6/58） |
| IDOR | 13 | 46 | 22%（13/59） |
| 路径遍历 | 5 | 31 | 13%（5/36） |
| SQL 注入 | 2 | 36 | 5%（2/38） |
| SSRF | 8 | 57 | 12%（8/65） |
| XSS | 12 | 62 | 16%（12/74） |
| 使用以下命令： |
claude --verbose
--print
--output-format json
--dangerously-skip-permissions
<PROMPT>
OpenAI Codex（v0.2.0，o4-mini/高推理）
| 漏洞类别 | 真阳性 | 假阳性 | 真阳性率 |
|---|---|---|---|
| 认证绕过 | 5 | 32 | 13%（5/37） |
| IDOR | 0 | 5 | 0%（0/5） |
| 路径遍历 | 8 | 9 | 47%（8/17） |
| SQL 注入 | 0 | 5 | 0%（0/5） |
| SSRF | 8 | 15 | 34%（8/23） |
| XSS | 0 | 28 | 0%（0/28） |
| 使用以下命令： |
codex --config disable_response_storage=true
--config model_reasoning_effort=high
--config model_reasoning_summary=detailed
exec
--model o4-mini
--full-auto
--skip-git-repo-check
<PROMPT>
我们的发现
- Claude Code 和 Codex 今天都很有用：它们发现了真实的安全漏洞，但它们非常嘈杂。 整体噪音仍然非常高，但它们在这些流行的开源 Python Web 应用程序中发现了真实的安全漏洞。总体而言，Claude Code 发现了 46 个漏洞（14% TPR，86% FPR），Codex 报告了 21 个漏洞（18% TPR，82% FPR）。
- 许多 IDOR bug 起初看起来是正确的，Claude Code 建议了可信的修复方案： 大语言模型不仅可以找到这些 bug，还可以建议可信的修复方案，比如基于代码中的现有模式注入新的权限检查。IDOR 问题可能很难分类，我们必须测试其中的大多数才能确定，这使得真阳性率低得多。
- Claude Code 作为一个好的安全护栏工具？ 许多发现虽然在技术上是假阳性，但仍然是很好的"护栏"建议，或者看起来像是这样。例如，模型通常会建议参数化一个已经安全的 SQL 查询。虽然不是漏洞，但这加强了代码。我们仍然认为这些是假阳性，尽管不像其他假阳性那么严重。
但是，这些代码强化建议并不总是可以信任的。我们发现了几个例子，特别是在客户端 JavaScript 代码中，AI 试图修复它认为的 DOM 操作周围的问题，但实际上，它破坏了代码（在我们观察的情况下是双重转义 HTML），尽管首先没有安全问题。
- XSS 和 SQL 注入 – 很难将组件拼凑在一起： 模型难以跟踪从服务器端框架到客户端组件的数据（XSS 的常见模式）或通过复杂的应用程序层。它经常被静态定义的数据混淆，或者无法识别服务器端的清理。
- 重复提示有助于获得更多结果： 大语言模型的概率性质意味着，以稍微不同的方式问同一个问题可以产生新的发现，突出了分析的不一致性。在同一个代码库上多次重复相同的提示给了我们不同的答案，但它最终会回到相同的发现。
- OpenAI Codex 有时无法报告有效的 SARIF。 我们预期的 66 份报告中有 9 份不是有效的 SARIF。我们考虑了这些文件中报告的所有发现，但它们不是有效的 SARIF 或 JSON。Claude Code 在我们尝试的任何情况下都没有这个问题。
相同的代码，相同的 AI，每次不同的 Bug：AI 编程智能体的非确定性问题
为了探索非确定性在实践中如何表现，我们选择了三个应用程序，并使用相同的提示多次运行相同的提示，针对相同的安全问题：IDOR。出现了一种模式：AI 的发现每次都不同。 在漏洞检测的背景下，这是一个主要问题。首先，作为一名安全工程师，理想情况下，我们希望有更强的保证，证明我们的代码已经扫描了重要的漏洞类别，而不是"我希望模型这次搜索得彻底"。 其次，间歇性地检测漏洞会导致你的安全工具或漏洞管理系统中的不一致和噪音。例如，如果你使用的是 SAST 平台、ASPM，或者你在内部构建的东西，通常这些系统假设当以前检测到的漏洞不再存在时，它已经被修复了。但对于大语言模型驱动的检测，情况可能并非如此，因为单次扫描可能会错过它，因此当后续扫描重新发现相同的问题时，会创建一个"新"发现，导致重复的 JIRA 工单和开发人员的挫败感。 以下是我们观察到的一些具体例子：
- PY-APP-007：在第一次运行中，AI 识别了一个"缺少搜索授权"漏洞，该漏洞在其他两次运行中不存在。第二次运行标记了该运行独有的问题。第三次运行又发现了它自己的一组独特的漏洞。
- PY-APP-006：类似的故事：第一次运行发现了用户 API 中的一个漏洞，而后续运行则专注于代码库的不同部分，例如事件摘要和笔记模块。
- PY-APP-002：这里的可变性可能是最明显的。识别的漏洞数量从第一次运行的 3 个跃升到第二次的 6 个，然后是 11 个。每次运行都呈现出不同的发现，这些发现只是部分重叠。
那么，这背后的原因是什么？我们认为关键因素是所谓的上下文腐烂 和 压缩。当 AI 智能体被赋予分析整个代码库的任务时，它正在处理大量信息：上下文腐烂导致无法从其自己的上下文中准确检索。为了管理这一点，大语言模型使用一种有损压缩形式（有时称为压缩），这意味着一些更精细的推理细节，如函数名称、路径等，可能会在总结过程中丢失。 把它想象成试图总结一部漫长而复杂的小说。你会捕捉到主要情节点，但你一定会错过一些微妙之处和细微差别。同样，AI 可能会忘记特定的架构模式或微妙的数据流，导致它在一次运行中错过一个漏洞，而在另一次运行中可能会捕捉到。我们在 PY-APP-006 中看到了一个明显的例子，其中 AI 提出的修复之一是不完整的，因为它没有重用现有的用户授权基类——这是在该特定运行中似乎丢失的关键上下文。 这种非确定性对于我们如何处理 AI 原生 SAST 具有重大意义。一方面，AI 每次"思考"不同的能力意味着它可以探索更广泛的潜在攻击向量，就像一个具有不同视角的人类渗透测试人员团队。另一方面，它引入了一定程度的不确定性，可能导致混淆或错误行为。
- 覆盖不完整：单次运行可能会提供虚假的安全感，因为它可能会错过在后续运行中可能被捕获的关键漏洞。
- 缺乏可重复性：无法重现结果使得难以验证 AI 的发现并以一致、可重复的方式信任其输出。
- 增加的成本和时间：需要运行多次审计以获得更完整的画面可能会显著增加所需的时间和计算资源。注意：对于传统软件，一旦你编写了它，你基本上可以"免费"再次运行它（不包括硬件成本、电力等）。对于大语言模型密集型工具来说，情况并非如此，在这种情况下，读取代码库并对其进行推理可能导致每次扫描数十到数百美元的令牌成本。这个成本可能会随着时间的推移而下降，但较新的模型可能会更昂贵。
Claude Code 的新 /security-review 命令效果如何？
Anthropic 发布了 Claude Code 的新命令，名为/security-review。它设计用于在拉取请求上运行，以检查更改的文件并提出问题以识别特定的安全问题。你可以在这里找到提示。
在整个代码库上运行此命令时，我们发现识别的安全问题相当有限。很多时候，它无法找到当我们提示 Claude Code 一次搜索一种特定安全问题时我们得到的安全问题。
我们在 PY-APP-003、PY-APP-002 和 PY-APP-008 上运行了这个命令，它在所有这些应用程序中只发现了一个 XSS，这与我们在整体实验中得到的结果非常不同。
回答我们的问题
让我们根据我们学到的知识重新审视我们最初的研究问题。
- FP/FN 率是多少？ 对于在现实世界代码上运行的原始 AI，假阳性率非常高，范围从 Codex 的路径遍历最好的 53% 或 Claude Code 的 IDOR 的 78%，到最坏的 Claude Code 的 SQL 注入的 95% 和 Codex 的 SQL 注入或 IDOR 的 100%。不同应用程序的性能也有很大差异，从 PY-APP-002（Claude Code）的 100%（10/10）真实 IDOR 到 PY-APP-007 的 0%（0/7）。在所有应用程序和所有报告的问题中，Claude Code 发现了 46 个漏洞（14% TPR，86% FPR），Codex 报告了 21 个漏洞（18% TPR，82% FPR）。
由于我们一直在使用真实的应用程序，我们无法在这个实验中准确测量假阴性。我们将在即将到来的博客文章中介绍测量假阴性率的技术！
- 它为什么失败？ 我们观察到的主要弱点是缺乏对注入问题代码执行的深层语义理解。模型难以处理过程间污点流和隐式流，这些是传统 SAST 引擎通常构建的东西。一些限制也来自上下文压缩和上下文腐烂。我们将继续更详细地探索这些限制，并探索缓解它们的解决方案。
- 脚手架和智能体工作流程有多重要？ 它们不仅仅重要；它们正在变得必不可少。安全审查中 AI 的未来不是单一的、整体的模型，而是 AI 智能体系统（包括我们案例中的编码智能体），可以使用工具、推理证据并协作来发现和验证漏洞。
虽然我们（尚未）有关于使用具有 Claude Code 访问权限的智能体与更典型的上下文工程（即构建脚手架以提供所有相关代码）与推理模型之间差异的数据，但我们观察到系统在复杂过程中工作并在报告安全问题的过程中做出明智决策的能力存在巨大差异。也就是说，一个反例是 Sean Heelan 如何能够做足够的上下文工程来让推理模型报告漏洞（8% 的时间）。我们真的建议你阅读 他的博客文章。
- 所有这一切中的成本如何？ 不幸的是，我们无法统一跟踪 Claude Code 和 Codex 之间的成本。Claude Code 的总成本为 114 美元，用于所有这些漏洞和所有这些应用程序（除了为非确定性和
/security-review命令运行）。
数据集：未来发布
我们今天不会发布数据集，也不会发布分析的开源应用程序的名称，因为我们正在进行负责任的披露过程，联系应用程序开发人员以获取所有安全问题的修复和验证。一旦完成，我们将放心地发布数据。
结论
大语言模型不是明天就会取代人类安全工程师的银弹，事实上，它们在端到端发现高严重性注入式漏洞方面相当薄弱。然而，它们是一个令人难以置信的强大工具。我们的研究表明，通过了解它们的优势（上下文推理）和弱点（代码的深层语义），并通过使用先进的静态分析引擎围绕它们构建复杂的智能体系统，我们可以创造新一代的安全工具，比以前的任何东西都要强大得多。
[1] Claude Code 和 Codex 的脚本化简单提示
BATCH_PROMPT_TEMPLATE = """
我是这个应用的核心开发者。据报告，代码库中有几个 {vuln_type} 漏洞。我需要你的专业知识来找到所有这些漏洞！
# 说明
- 在我的代码中找到所有 {vuln_type} 漏洞，不要担心第三方代码。
- 解释为什么它们是我应该关心的真实安全漏洞；给出代码片段来支持你的分析（从入口点跟踪）；可能还有一些关于如何触发问题进行测试的线索。
- 使用你将在 <SARIF_OUTPUT>...</SARIF_OUTPUT> 标签内编写的 SARIF JSON 格式报告所有 {vuln_type} 漏洞；确保它是有效的 JSON。
- 修复代码中的这些安全问题。
不要要求确认，直接去做。
"""