OpenAI 介绍了 Codex Security 为什么不以传统 SAST 报告为输入，而是直接从代码库与威胁建模出发，结合约束推理、微化测试和沙箱验证来发现可复现的高置信度漏洞，从而减少误报与不必要的人工复核。文章指出许多实际漏洞来自校验与解释顺序、规范化与解析差异导致的约束传播失效，而非单纯的数据流问题。
背景与设计原则
- 传统 SAST：追踪不可信输入到敏感 sink，是可扩展的静态检测方法，但为可行性做了许多近似，面对回调、反射和框架控制流等问题时容易产生假阳性或遗漏。
- Codex Security 的出发点：从仓库上下文（架构、信任边界、意图）入手，尽量在提示人工前就验证发现，强调“校验是否真正约束了值”，而非仅仅检测校验调用存在与否。
常见弱点示例
- 顺序问题：例如先做正则校验再 URL 解码，可能导致解码后的值跳过校验。
- 部分规范化与解析歧义：检查环节和最终解释环节对输入的处理不一致，会破坏安全不变式。
- 实例引用：CVE-2024-29041 中的 open redirect 就是因编码与解释顺序导致允许绕过白名单。
Codex Security 的方法论
- 以人类研究者的方式阅读相关代码路径，结合注释与上下文判断意图（但不盲置信息性注释）。
- 提取最小可测切片并为其生成微模糊测试（micro-fuzzers），方便复现边界情况。
- 在必要时将约束问题形式化为可满足性问题（如用 z3 求解），用于处理复杂约束或非标准架构的整数溢出等问题。
- 在隔离的沙箱或编译调试环境中执行假设并生成端到端 PoC，以把“可能的问题”升级为“确凿的问题”。
为什么不先用 SAST 再深挖？
- 容易造成聚焦偏差：以 SAST 发现为起点会偏向工具已覆盖的区域，遗漏其他类问题。
- 隐含判断难以逆转：SAST 的预设可能把 agent 引导为确认或否定已有结论，而非独立调查。
- 评估困难：混用 SAST 输出与 agent 自身发现，会妨碍对 agent 能力的独立评估与持续改进。
结论
- Codex Security 选择直接从代码与系统意图出发，利用约束推理、微测试与实际执行验证来提高问题证据强度并降低人工复核负担；但并不否定 SAST 在特定已知漏洞类的价值。
把“检查存在”转为“检查有效”是发现真实漏洞并降低误报的关键。