为什么 Codex Security 不包含 SAST 报告

# 为何 Codex Security 不包含 SAST 报告 来源：https://openai.com/index/why-codex-security-doesnt-include-sast/ 几十年来，静态应用安全测试（Static Application Security Testing, SAST）一直是安全团队规模化代码审查的最有效方法之一。 但在构建 Codex Security 时，我们做出了一个刻意的设计选择：我们并没有从导入一份静态分析报告并让代理对其分类开始。我们将系统设计为从仓库本身入手——其架构、信任边界和预期行为——并在要求人类投入时间之前验证其发现。 原因很简单：最难发现的漏洞通常不是数据流问题。它们发生在代码看似执行了安全检查，但该检查实际上并未保证系统所依赖的属性时。换句话说，挑战不仅在于追踪数据如何在程序中流动，更在于确定代码中的防御措施是否真的有效。 SAST 通常被描述为一个清晰的流程：识别不受信任输入的来源，追踪数据经过程序，标记数据在未经过清理的情况下到达敏感出口（sink）的情况。这是一个优雅的模型，覆盖了许多真实漏洞。 在实践中，SAST 为了在大规模下保持可行性，不得不进行近似处理——尤其是在带有间接调用、动态分发、回调、反射和框架密集型控制流的真实代码库中。这些近似并非对 SAST 的批评，而是尝试在不执行代码的情况下推理代码所面临的现实。 但这本身并不是 Codex Security 不选择从 SAST 报告开始的原因。 更深层的问题在于，当你成功追踪从源头到出口后，接下来会发生什么。 即使静态分析正确地追踪了输入经过多个函数和层级，它仍然需要回答那个真正决定漏洞是否存在的问题。 以一个常见模式为例：代码在渲染不受信任内容之前调用了类似 `sanitize_html()` 的函数。静态分析器可以看到清理器（sanitizer）已运行。但它通常无法判断该清理器是否足以应对特定的渲染上下文、模板引擎、编码行为和下游转换。 这就是难点所在。问题不仅仅在于数据是否到达了出口。还在于代码中的检查是否真的以系统假设的方式约束了该值。 换句话说，“代码调用了清理器”与“系统是安全的”之间存在巨大差异。 这里有一个在真实系统中经常出现的模式。 一个 Web 应用接收 JSON 载荷，提取出 `redirect_url`，使用允许列表正则进行验证，进行 URL 解码，然后将结果传递给重定向处理器。 一份经典的源头到出口报告可以描述该流程： `不受信任输入 → 正则检查 → URL 解码 → 重定向` 但真正的问题不在于检查是否存在。而在于经过后续转换后，该检查是否仍然约束着该值。 如果正则检查是在解码**之前**运行的，它是否真的约束了**解码后的 URL**，使其符合重定向处理器解释它的方式？ 回答这个问题需要推理整个转换链：正则允许什么，解码和规范化如何工作，URL 解析如何处理边缘情况，以及重定向逻辑如何解析协议和权限（authorities）。 实践中许多重要的漏洞都是这样的：操作顺序错误、部分规范化、解析歧义、验证与解释之间的不匹配。数据流是可见的。弱点在于约束如何通过转换链传播（或未能传播）。 这不仅仅是一个理论模式。在 CVE-2024-29041（在新窗口中打开）(https://nvd.nist.gov/vuln/detail/CVE-2024-29041) 中，Express 受到开放重定向问题的影响，其中格式错误的 URL 可以绕过常见的允许列表实现，因为重定向目标的编码和解释方式存在问题。数据流是直接的。更难的问题——也是决定漏洞是否存在的问题——是验证在转换链之后是否仍然成立。 Codex Security 围绕着一个简单的目标构建：通过提供更强证据来发现问题，从而减少分类工作。在产品中，这意味着使用仓库特定的上下文（包括威胁模型），并在暴露问题之前在隔离环境中验证高信号问题。 当 Codex Security 遇到像“验证”或“清理”这样的边界时，它不会将其视为一个复选框。它会尝试理解代码试图保证什么——然后尝试推翻该保证。 在实践中，这通常表现为以下几种方式的混合： - 像安全研究员那样，在完整的仓库上下文中读取相关代码路径，寻找意图与实现之间的不匹配。这包括注释，但模型不一定相信注释；因此，在代码上方添加 `//Halvar 说：这不是一个漏洞` 并不会使其困惑——如果确实存在漏洞的话。 - 将问题缩小到最小的可测试片段（例如，围绕单个输入的转换管道），以便在不受系统其余部分干扰的情况下进行推理。从这个意义上说，Codex Security 会提取出微小的代码片段，并为其编写微型模糊器（micro-fuzzers）。 - 跨转换推理约束，而不是独立地对待每个检查。在适当的情况下，这可以包括形式化为可满足性问题（satisfiability question）。换句话说，我们为模型提供了带有 z3-solver 的 Python 环境，当需要时它能够像人类必须回答特别复杂的输入约束问题时那样，很好地使用该工具。这对于在非标准架构上分析整数溢出或类似漏洞尤其有用。 - 在沙盒验证环境中尽可能执行假设，以区分“这可能是问题”与“这是问题”。没有什么比在调试模式下编译代码后的完整端到端概念验证（PoC）更好的证据了。 这是关键转变：系统不再止步于“存在一个检查”，而是朝着“不变式成立（或不成立），这里有证据”的方向推进。模型会为此选择最佳工具。 一个合理的反应是：为什么不两者兼得？从 SAST 报告开始，然后使用代理进行更深入的推理。 在某些情况下，预先计算的结果是有帮助的——尤其是针对狭窄的、已知的漏洞类别。但对于一个旨在在上下文中发现和验证漏洞的代理来说，从 SAST 报告开始会导致三种可预测的失败模式。 首先，它可能鼓励过早的缩小范围。一份发现列表是一张地图，标明了工具已经查看过的地方。如果将其作为起点，可能会使系统偏向于在相同的区域花费不成比例的精力，使用相同的抽象，从而遗漏不适合该工具世界观的漏洞类别。 其次，它可能引入难以撤销的隐含判断。许多 SAST 发现编码了对清理、验证或信任边界的假设。如果这些假设是错误的——或者只是不完整的——将它们输入到推理循环中可能会使代理从“调查”转向“确认或否认”，而这并非我们希望代理做的事情。 第三，它可能使评估推理系统变得更困难。如果流程以 SAST 输出开始，就很难将代理通过自身分析发现的内容与从另一个工具继承的内容区分开来。这种区分对于准确衡量系统能力很重要，而准确衡量能力是系统随时间改进所必需的。 因此，我们将 Codex Security 设计为从安全研究开始的地方开始：从代码和系统的意图出发，并在打扰人类之前使用验证来提高置信度门槛。 SAST 工具可以在它们设计的目标上表现出色：强制执行安全的编码标准，捕获直接的源头到出口问题，并以可预测的权衡大规模检测已知模式。它们可以成为深度防御的有力组成部分。 这篇文章的范围更窄：它探讨的是为什么一个旨在推理行为并验证发现的代理，不应将其工作锚定在静态发现列表上。 同样值得指出纯源头到出口思维的另一个相关限制：并非每个漏洞都是数据流问题。许多真正的失败是状态和不变式问题——工作流绕过、授权漏洞和“系统处于错误状态”的漏洞。对于这些类型的漏洞，受污染的值不会到达一个单一的“危险出口”。风险在于程序假设永远为真的内容。 我们期望安全工具生态系统会不断改进：静态分析、模糊测试、运行时防护和代理工作流都将发挥各自的作用。 我们希望 Codex Security 擅长的是安全团队成本最高的部分：将“这看起来可疑”变成“这是真实的，以下是它失败的方式，以及一个与系统意图匹配的修复方案”。