Why Codex Security Doesn’t Include a SAST Report

OpenAI has published details explaining why Codex Security does not rely on traditional static application security testing reports. According to OpenAI, the system was deliberately designed to start with the repository itself, examining its architecture, trust boundaries, and intended behavior, rather than importing a static analysis report for an agent to triage. The core limitation of traditional SAST is that while it can track dataflows from sources to sinks, it struggles to determine whether validation or sanitization checks are actually sufficient for specific contexts, such as handling order-of-operations mistakes, partial normalization, and transformation chains. To address this, Codex Security uses repo-specific context and threat models to validate high-signal issues in isolated environments. The system reads relevant code paths like a security researcher, isolates small code slices to write micro-fuzzers, reasons about constraints across transformations using tools like z3-solver in a Python environment, and executes hypotheses in sandboxed validation environments to generate end-to-end proofs of concept. OpenAI notes that starting with a SAST report creates three predictable failure modes for an AI agent: encouraging premature narrowing based on where a tool already looked, introducing implicit and potentially incomplete judgments that shift the agent into a confirmation bias, and making it difficult to accurately evaluate what the agent discovered independently versus what it inherited from another tool. While SAST tools remain valuable for enforcing secure coding standards and catching straightforward source-to-sink issues, OpenAI built Codex Security to begin directly from the code and system intent.