OpenAI Codex 安全：为何系统避免使用 SAST 报告进行种子化
OpenAI 设计了 Codex 安全，以基于架构、信任边界和预期行为来分析代码库，而不是对已有的静态应用安全测试（SAST）报告进行分类处理。这种方法确保系统关注安全防御在实际运行中是否真的有效，而不是仅仅验证代码中是否存在安全检查。
在复杂漏洞检测中的 SAST 局限性
静态应用安全测试（SAST）主要针对数据流分析进行优化——追踪不可信输入从来源到敏感汇点的路径。虽然对许多错误有效，但该模型在现代代码库的语义实际情况面前常常力不从心。
数据流 vs. 安全不变量
SAST 工具常能识别出已调用了某个清理函数（例如 sanitize_html()），但它们通常无法判断该清理函数在特定渲染上下文、模板引擎或后续转换中是否足够。关键的差距在于“代码调用了清理函数”这一事实与“系统是安全的”这一结论之间的区别。
转换链的挑战
许多关键漏洞源于操作顺序错误或解析歧义，导致检查在一次转换后被绕过。例如，如果正则验证在 URL 解码之前进行，解码后的 URL 可能不再受原始检查的约束。OpenAI 以 Express 中的 CVE-2024-29041 为例，说明数据流本身很直接，但漏洞产生于验证在转换链后失效。
Codex 安全的行为验证方法
Codex 安全不把安全检查当作复选框，而是尝试理解代码片段的预期保证，然后通过多种技术手段尝试推翻该保证：
- 上下文分析： 系统在完整的代码库上下文（包括注释）中读取代码路径，以识别意图与实现之间的不匹配。
- 微模糊测试： 系统提取转换管道中最小的可测试切片，并编写微模糊测试器对其进行孤立测试。
- 约束推理： 对于复杂的输入约束（例如非标准架构上的整数溢出），系统使用配备
z3-solver的 Python 环境，将问题形式化为可满足性查询。 - 沙箱执行： 系统在沙箱环境中执行假设，生成以调试模式编译的端到端概念验证（PoC），以区分理论风险和实际漏洞。
为什么 Codex 安全不从 SAST 报告中种子化
OpenAI 明确避免使用 SAST 报告作为代理的起点，以规避三种特定的失败模式：
- 过早收窄范围： 从发现列表开始会使代理偏向工具已识别的区域和抽象，可能遗漏超出工具视野的问题。
- 隐式判断： SAST 发现常常编码了对信任边界的假设。如果这些假设错误，代理可能从“调查”转为仅仅“确认或驳回”工具的假设。
- 评估困难： 以 SAST 输出为种子会使衡量代理独立发现能力变得困难，而这对于迭代系统改进是必需的。
SAST 在深度防御中的角色
OpenAI 指出，SAST 工具仍然是强制安全编码标准和大规模检测已知模式的关键手段。然而，它们不足以发现状态和不变量问题——例如授权缺口或工作流绕过——这些情况下没有单一的“受污染值”流向“危险汇点”，而是程序对系统状态的根本假设被违背。