> OpenAI 认为，传统 SAST 更擅长“从 source 到 sink 的数据流跟踪”，但很多真正重要的安全问题，关键不在于数据有没有流到危险点，而在于代码中的防御约束在一连串转换后是否仍然成立。 Codex Security 的设计重点不是先读一份静态分析报告再做分诊，而是直接从仓库上下文、系统意图和信任边界出发，理解代码想保证什么，再主动验证这些保证是否真的成立。 文章举的核心例子是“先校验、后解码”的 URL 重定向场景：表面上存在 allowlist 检查，但在解码、归一化和解析之后，约束可能已经失效，而这正是许多真实漏洞产生的地方。 OpenAI 不是否定 SAST 的价值，而是强调：对于一个要在真实仓库中发现并验证漏洞的 agent 来说，过早锚定在 SAST findings 上，容易造成搜索空间收窄、继承错误前提、并妨碍独立评估 agent 的真实推理能力。
> 原文：Original
这篇文章讨论的不是“静态应用安全测试有没有用”，而是另一个更具体的问题：如果你在做一个会自己阅读代码、理解系统行为、尝试验证漏洞并给出修复建议的安全 Agent，那么它的起点到底应该是什么？
OpenAI 给出的答案很明确：不应该先把一份 SAST 报告喂进去，再让 Agent 围绕这份结果做分诊。他们认为，这样的起点虽然看起来高效，但会把系统过早绑定到静态分析工具既有的视角上，反而削弱了 Agent 去理解真实行为、发现约束失效和验证漏洞是否成立的能力。
SAST 的经典工作方式，是从不受信任输入出发，跟踪数据在程序中的传播路径，最后判断它是否在缺少适当处理的情况下流入了危险 sink。这个范式非常优雅，也确实抓住了大量现实中的漏洞。
但 OpenAI 文章强调，SAST 为了在大规模代码库中保持可计算性，必须做很多近似处理。真实系统里有大量间接调用、动态分发、回调、反射、框架封装和复杂控制流，而静态分析不执行代码，只能通过抽象近似去推断。这不是 SAST “不好”，而是它天然的代价和边界。
不过，OpenAI 认为这还不是关键矛盾。真正更深的一层问题在于：即使你已经成功把 source 跟到 sink，真正决定漏洞是否存在的，也往往不是“流到了没”，而是“中间那道防线到底有没有真的起作用”。
文章里举了一个非常典型的例子：代码在渲染不受信任内容之前，先调用了类似 sanitize_html() 的函数。静态分析器通常能看见“这里调用过 sanitizer”，但它很难进一步判断：
换句话说，“代码调用了清洗函数”和“系统真的安全”之间，差着整整一层语义验证。
这正是 OpenAI 想强调的重点：很多高价值漏洞并不是单纯的数据流问题，而是约束如何在一连串转换中传播、失效或者被误解的问题。
文中最关键的案例，是一个常见的跳转逻辑：Web 应用接收 JSON 请求，取出 redirect_url，先用 allowlist 正则校验，再做 URL decode，最后传给 redirect handler。
如果只看传统 source-to-sink 视角，这条链路其实已经很清楚：
不受信任输入 → 正则校验 → URL 解码 → 重定向
但真正该问的问题不是“有没有做检查”，而是：这道检查在后续变换之后是否仍然有效？
如果正则发生在解码之前，那么它约束的到底是“编码前的字符串”，还是最终被 redirect handler 真正解释的那个 URL？当解码、归一化、URL 解析、scheme 和 authority 解析规则都参与进来之后，前面的那层 allowlist 可能早就不再覆盖真正的风险边界。
OpenAI 用这个例子说明，现实里的许多漏洞就是这样出现的：
也就是说，数据流本身并不隐藏，真正脆弱的是“约束的连续性”。
因此，Codex Security 的设计重点不是“拿现成 findings 进来排序”，而是从仓库本身开始：理解项目结构、威胁模型、信任边界和系统意图，再围绕高信号问题做验证。
文章提到，当 Codex Security 遇到看起来像“校验”或“清洗”的边界时，它不会把那当作一个简单的 checkbox，而是会继续追问：
实践上，这会体现为几种典型动作：
这里最重要的转变是：系统不满足于“这里看起来有个检查”，而是继续往前推进到“这个不变量到底成立还是不成立，这里有证据”。
OpenAI 也正面回答了一个很自然的反问：那为什么不两者都要？先跑 SAST，再让 Agent 深入推理，不是更省事吗？
他们给出的理由主要有三点。
一份 findings list，本质上已经是某个工具“看过哪些地方、按什么抽象看、觉得哪里值得关注”的结果。如果 Agent 从这里开始，很容易把大部分精力继续投到同样的区域和同样的思维框架中，结果是：
很多 SAST finding 并不只是“发现一条路径”，里面还隐含了对 sanitization、validation、trust boundary 的前提判断。如果这些前提本身就是错的，或者只是局部成立，那么把它们喂给 Agent，相当于在一开始就给了它一个带偏的世界模型。
这样一来，Agent 容易从“独立调查”变成“围绕既有结论做确认或驳回”，这和 OpenAI 想要的研究式工作方式并不一致。
如果一整条 pipeline 是从 SAST 输出开始，那么你很难区分：
而这种区分，对于持续评估和提升系统本身的能力非常关键。
文章专门留出一节强调：SAST 仍然非常重要。
OpenAI 并没有说静态分析没价值，也没有宣称所有安全工作都该交给 agent。相反，他们承认 SAST 在以下场景依然很强：
也就是说，SAST 仍然是 defense-in-depth 的重要组成部分。
文章真正的论点更窄，也更锋利：对于一个要在真实上下文中发现并验证漏洞的 Agent 来说，不应该把 SAST findings list 当作默认起点。
OpenAI 还顺手指出了另一层经常被忽视的问题：并不是所有高风险漏洞都能被归结为“污点值流到危险 sink”。
很多真实系统的失败来自：
这类问题本质上更像“状态和不变量问题”，而不是经典的 source-to-sink 问题。也正因为如此，一个围绕系统意图、行为验证和不变量失效来设计的 Agent，会比单纯围绕 finding triage 来构建的系统更贴近真实安全工作。
我觉得这篇文章最值得看的地方，不是它替 Codex Security 做产品宣传，而是它把一个很现实的分水岭讲清楚了：安全 Agent 到底是在“消费安全工具输出”，还是在“像研究员一样理解系统、提出假设并验证假设”。
前一种路线更像自动化分诊，优点是容易接入已有流程；后一种路线更难做，但也更接近真正高价值漏洞挖掘的工作形态。
OpenAI 在这里显然押注后者。它认为最难、也最值钱的问题，往往出现在“代码看似做了防护，但这个防护在语义上并没有真的成立”的地方。而这类问题，光靠传统 SAST finding 往往不够，必须结合上下文理解、约束传播分析、最小切片验证和实际执行来确认。
如果你把这篇文章放到更大的背景里看，它其实也在表达一个趋势：未来的安全工具链不会是“静态分析 vs Agent”二选一，而会是多种能力叠加。但在这条链里，Agent 想真正有独立价值，就不能只做 findings 的二次加工，而必须能直接面对代码和系统意图，自己把问题推到“可证伪、可复现、可修复”的层级。