📢 转载信息
原文链接：https://openai.com/index/why-codex-security-doesnt-include-sast
原文作者：OpenAI
几十年来，静态应用安全测试 (SAST) 一直是安全团队扩展代码审查能力最有效的方式之一。
但在构建 Codex Security 时，我们做了一个深思熟虑的设计决策：我们并没有从导入静态分析报告并要求智能体进行漏洞分级开始。我们让系统直接从代码仓库本身开始分析，包括架构、信任边界以及预期行为。在需要人工介入之前，系统会先对发现的问题进行校验。
原因很简单：很多最难发现的漏洞，并不只是数据流问题。当代码看似执行了安全检查，但该检查实际上并不能保证系统所依赖的安全性属性时，漏洞就会发生。挑战不仅仅是追踪数据在程序中如何流动，而是确定代码中的防御机制是否真的有效。
问题所在：SAST 是针对数据流优化的
SAST 通常被描述为清晰的流水线：识别不可信输入的源头，追踪数据在程序中的流向，并标记那些未经过滤处理就到达敏感汇聚点的案例。这是一个优雅的模型，且涵盖了许多真实的漏洞。
但在实践中，为了在大规模代码库上保持可计算性，SAST 必须进行近似处理。这些近似处理并非 SAST 的缺陷，而是试图在不执行代码的情况下对代码进行静态推理的必然现实。更深层次的问题在于：当你成功追踪了从源头到汇聚点的路径后，仅仅确定路径是不够的，你还必须回答：防御措施真的有效吗？
示例：解码前的校验
一个 Web 应用程序接收一个 JSON 负载，提取 redirect_url，通过白名单正则表达式对其进行校验，接着进行 URL 解码，最后将结果传递给重定向处理程序。一份经典的“源头到汇聚点”报告认为流程是安全的，因为有正则检查。
但真正的问题在于：如果正则校验运行在解码之前，它是否真的约束了解码后的 URL？许多重要漏洞（如 CVE-2024-29041）往往源于操作顺序错误、部分标准化处理或解析歧义。数据流看似清晰，但校验在后续转换过程中能否持续生效才是关键。
我们的方法：从行为出发，随后校验
Codex Security 的构建围绕一个简单的目标：通过呈现带有更强证据的问题来减少筛选成本。它的核心做法包括：
- 结合完整的代码仓库上下文：像安全研究员一样寻找意图与实现之间的不匹配。
- 将问题缩小到最小可验证单元：为特定的转换流水线编写微型模糊测试工具 (Micro-fuzzer)。
- 分析约束在多次转换中的传播情况：在必要时像人类一样使用 z3-solver 等工具解决复杂的输入约束。
- 在沙箱校验环境中执行假设：旨在区分“这可能是一个问题”与“这确实是一个问题”。
为什么不直接利用 SAST 报告？
对于一个旨在结合上下文进行深度推理的智能体来说，从 SAST 报告开始会引发三种可预测的失败模式：
- 过早缩小范围：系统会产生偏见，漏掉那些不符合工具“世界观”的问题类别。
- 引入难以消除的隐含判断：如果 SAST 的假设是不完整的，将这些假设喂入推理循环会误导智能体。
- 增加评估难度：难以区分哪些漏洞是智能体自身发现的，哪些是继承自现有工具的。
我们预见安全工具生态系统将持续改进。Codex Security 的价值在于：把“看起来可疑”的问题，转变为“确认存在的漏洞”，并给出符合系统设计意图的修复方案。
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区