📢 转载信息
原文链接：https://openai.com/index/why-codex-security-doesnt-include-sast
原文作者：OpenAI
几十年来，静态应用程序安全测试（SAST）一直是安全团队扩展代码审查最有效的方法之一。
但是，当我们构建 Codex Security 时，我们做了一个深思熟虑的设计选择：我们没有先导入静态分析报告并要求代理进行分类。我们设计系统时，是从代码库本身开始——它的架构、信任边界和预期行为——并在要求人工投入时间之前验证其发现。
原因很简单：最难发现的漏洞通常不是数据流问题。它们发生在代码似乎强制执行了安全检查，但该检查实际上并未保证系统所依赖的属性。换句话说，挑战不仅仅是跟踪数据如何在程序中流动——而是确定代码中的防御措施是否真的有效。
SAST 针对数据流进行优化
SAST 通常被描述为一个清晰的管道：识别不受信任输入的来源，跟踪程序中的数据，并在数据未经清理就到达敏感“汇”时发出警告。这是一个简洁的模型，并且涵盖了许多实际存在的错误。
实际上，为了在规模上保持可行性，SAST 必须做出近似——尤其是在具有间接引用、动态分派、回调、反射和大量框架控制流的真实代码库中。这些近似并不是对 SAST 的批评；而是试图在不执行代码的情况下进行推理的现实。
仅凭这一点，并不是 Codex Security 不从 SAST 报告开始的原因。
更深层的问题是，当你成功地将源追踪到汇之后会发生什么。
静态分析的难点：约束和语义
即使静态分析正确地跨越多个函数和层追踪输入，它仍然需要回答一个真正决定漏洞是否存在的问题：
防御措施是否真的有效？
以一个常见的模式为例：代码调用类似 sanitize_html() 的函数，然后渲染不受信任的内容。静态分析器可以看到已调用清理函数。但它通常无法确定该清理函数对于特定的渲染上下文、模板引擎、编码行为和下游转换是否足够。
这时情况就变得棘手了。问题不仅仅是数据是否到达了“汇”。问题在于代码中的检查是否确实限制了值，就像系统假设的那样。
换句话说：“代码调用了清理函数”与“系统是安全的”之间存在巨大差异。
示例：解码前的验证
以下是一个在实际系统中经常出现的模式。
Web 应用程序接收 JSON 有效负载，提取 redirect_url，使用允许列表正则表达式对其进行验证，对其进行 URL 解码，然后将结果传递给重定向处理程序。
经典的“源到汇”报告可以描述这种流程：
不受信任的输入 → 正则表达式检查 → URL 解码 → 重定向
但真正的问题不是检查是否存在。而是该检查在后续转换之后是否仍然限制了值。
如果正则表达式运行在解码之前，它是否真的限制了解码后的 URL，正如重定向处理程序所解释的那样？
回答这个问题需要推理整个转换链：正则表达式允许什么，解码和规范化是如何工作的，URL 解析如何处理边缘情况，以及重定向逻辑如何解析方案和权限。
实践中许多重要的漏洞都表现为这种模式：操作顺序错误、部分规范化、解析歧义以及验证与解释之间的不匹配。数据流是可见的。弱点在于约束如何通过转换链传播——或未能传播。
这不仅仅是一个理论模式。在CVE-2024-29041（在新窗口中打开）中，Express 受到了一个开放重定向问题的困扰，其中由于重定向目标是如何编码和随后解释的，畸形的 URL 可以绕过常见的允许列表实现。数据流是直观的。更难的问题——也是决定错误是否存在的问题——是验证在转换链之后是否仍然有效。
我们的方法：从行为开始，然后验证
Codex Security 的构建围绕一个简单的目标：通过提供更强的证据来减少分类工作。在产品中，这意味着利用特定于代码库的上下文（包括威胁模型），并在将发现的漏洞呈现给人类之前，在隔离的环境中进行验证。
当 Codex Security 遇到看起来像“验证”或“清理”的边界时，它不会将其视为一个复选框。它试图理解代码试图保证什么——然后它试图证伪该保证。
实际上，这通常看起来是以下几点的结合：
- 使用完整的代码库上下文阅读相关的代码路径，就像安全研究人员那样，寻找意图和实现之间的不匹配。这包括注释，但模型不一定相信注释，因此在代码上方添加 //Halvar says: this is not a bug 并不会让它感到困惑，如果确实存在错误的话。
- 将问题简化为最小的可测试片段（例如，单个输入周围的转换管道），以便您可以在不被系统其他部分干扰的情况下对其进行推理。从这个意义上说，Codex Security 会提取微小的代码片段，然后为它们编写微型模糊器。
- 推理跨转换的约束，而不是独立处理每个检查。在适当的情况下，这可以包括将问题形式化为可满足性问题。换句话说，我们让模型访问一个带有 z3-solver 的 Python 环境，当需要时，它善于使用它，就像人类在回答特别复杂的输入约束问题时必须做的那样。这对于查看非标准架构上的整数溢出或类似错误特别有用。
- 在可能的情况下，在沙盒化的验证环境中执行假设，以区分“这可能是一个问题”和“这是一个问题”。没有什么比完整的端到端 PoC（以调试模式编译代码）更好的证明了。
这是关键的转变：系统不再停留在“存在检查”上，而是朝着“不变量成立（或不成立），以下是证据”的方向发展。模型会选择最适合这项工作的工具。
我们为什么不将 SAST 报告作为 Codex Security 的种子
一个合理的反应是：为什么不两者都做呢？从 SAST 报告开始，然后使用代理进行更深入的推理。
在某些情况下，预先计算的发现是有帮助的——特别是对于狭窄的、已知的错误类别。但对于一个旨在在上下文中发现和验证漏洞的代理来说，从 SAST 报告开始会产生三种可预见的失败模式。
首先，它可能鼓励过早的范围缩小。发现列表是工具已经查看过的位置的地图。如果你把它作为起点，你可能会使系统倾向于在同一区域花费不成比例的精力，使用相同的抽象，并错过那些不符合工具世界观的错误类别。
其次，它可能引入难以消除的隐式判断。许多 SAST 发现都编码了关于清理、验证或信任边界的假设。如果这些假设是错误的——或者仅仅是不完整的——将它们输入推理循环可能会将代理从“调查”转变为“确认或驳回”，这并非我们希望代理做的事情。
第三，它可能使评估推理系统变得更加困难。如果管道从 SAST 输出开始，就很难区分代理通过自身分析发现的内容和它从另一个工具继承的内容。如果你想准确衡量系统的能力，这种分离很重要，因为这对于系统的持续改进是必需的。
因此，我们构建 Codex Security 以安全研究开始的地方开始：从代码和系统的意图出发，并使用验证来提高置信度，然后再打扰人类。
SAST 工具仍然非常重要
SAST 工具在其设计目标方面可能非常出色：强制执行安全编码标准，捕获直接的源到汇问题，并以可预测的权衡在规模上检测已知模式。它们可以是纵深防御的有力组成部分。
这篇帖子范围更窄：它讨论的是一个旨在推理行为和验证发现的代理为什么不应该以静态发现列表为锚定来开始其工作。
也值得指出纯粹的“源到汇”思维的一个相关局限性：并非所有漏洞都是数据流问题。许多实际的失败是状态和不变量问题——工作流绕过、授权差距和“系统状态错误”的错误。对于这些类型的错误，污点值不会到达单个“危险的汇”。风险在于程序始终假定的内容。
展望未来
我们预计安全工具生态系统将不断改进：静态分析、模糊测试、运行时保护和代理工作流都将发挥作用。
我们希望 Codex Security 擅长的是那些给安全团队带来最大成本的部分：将“看起来可疑”转化为“这是真的，它是如何失败的，以及这是一个符合系统意图的修复”。
如果您想了解更多关于 Codex Security 如何扫描代码库、验证发现并提出修复建议，请参阅我们的文档（在新窗口中打开）。
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区