OpenAI Explains Codex Security’s SAST-Free Design

OpenAI used a March 16 explainer to define Codex Security more narrowly than “AI SAST.” In Why Codex Security Doesn’t Include a SAST Report, the company says the product is intentionally built to reason from repository context, validate exploitability, and propose fixes, instead of starting from a traditional static analysis report. If you run AppSec tooling in CI, this matters because it draws a clean product boundary: Codex Security is positioned as a high-confidence semantic reviewer, not a broader deterministic scanner.

Product boundary

The underlying product launched on March 6 in research preview for ChatGPT Pro, Enterprise, Business, and Edu users through Codex web, with free usage for the first month. It works on connected GitHub repositories, scans merged commits and repository history, validates likely issues in isolated environments, and suggests patches that humans can review before opening a PR.

The March 16 post explains why OpenAI did not make the system consume SAST output as a starting point. The short answer is search quality. Seeding the agent with another tool’s report narrows attention to places that tool already flagged, carries forward assumptions about sanitization and trust boundaries, and makes it harder to measure what the reasoning system actually found on its own.

Why SAST was excluded from the starting point

The technical distinction OpenAI emphasizes is between source-to-sink dataflow and semantic security properties. Traditional SAST is strong at deterministic coverage for known patterns and straightforward taint-style analysis. Codex Security is aimed at failures involving constraints, transformations, state, workflow, and invariants.

The example OpenAI uses is a redirect_url validated by regex before URL decoding. The security question is whether the check still constrains the value after decoding and parsing, not whether a validation function exists. OpenAI points to CVE-2024-29041 in Express as the kind of transformation-chain bug that exposes this gap.

For developers, the implication is direct. If your codebase has defenses that depend on order of operations, framework semantics, encoding boundaries, or authorization assumptions spread across multiple files, a SAST-first pipeline can miss the real failure mode because the interesting bug is often in the mismatch between checks and behavior.

Detection pipeline

Codex Security starts from the repository and a repository-specific threat model. It then reads relevant code paths, reduces suspicious logic into a smaller testable slice, reasons across transformations, and validates the hypothesis when possible.

OpenAI says the system can formalize parts of the problem with z3-solver in a Python environment. It can also use micro-fuzzers and sandboxed end-to-end validation rather than stop once it sees a sanitizer in the path. This is a meaningful design choice for anyone building AI agents for engineering workflows, because the value comes from tool-using verification, not only text generation.

The operational model is also more agentic than report-based scanners. Analysis and validation run in ephemeral isolated containers, the target repository is cloned temporarily, artifacts are extracted for review, and the container is torn down after the job finishes. The current workflow is tied to Codex Web and Codex Cloud, not a general self-serve API product.

Report format and triage strategy

OpenAI is optimizing for fewer, stronger findings. The UI surfaces Recommended Findings, an evolving top 10 most critical issues, alongside All Findings. Findings can include file paths, code excerpts, reasoning context, validation steps, validation output, and patch proposals.

This is the core product bet. Security teams do not need another long list of unactionable warnings. They need findings with evidence. The same pressure exists in other agent systems, where evaluating agents depends less on raw output volume and more on whether the system can complete a task with verifiable correctness.

Official metrics so far

OpenAI disclosed several preview-stage numbers from the March 6 rollout.

Metric	OpenAI figure
Commits scanned over prior 30 days	1.2M+
Critical findings	792
High-severity findings	10,561
Critical issues as share of scanned commits	under 0.1%
Noise reduction in one repeated-repo comparison	84%
Reduction in over-reported severity	90%+
False-positive reduction across repositories	50%+

Those numbers support the positioning: lower-noise, evidence-backed findings over exhaustive scanner output. Pricing after the free month has not been disclosed.

Where this fits with existing AppSec stacks

OpenAI does not present Codex Security as a replacement for SAST. The stated role is complementary. SAST still gives broad deterministic coverage. Codex Security adds semantic reasoning, validation, and patch suggestions in repository context.

That complementarity is important if you already use code review automation or AI coding tools. A coding assistant helps generate and modify code. A security agent has a different burden of proof. It needs to show exploitability or a validated failure mode. The gap between generation and verification is the same one that shows up in modern AI code review and broader coding workflows.

If you evaluate Codex Security, do it against your triage queue, not your scanner checklist. Measure whether the repository-specific threat model is accurate, whether validation artifacts help reviewers decide faster, and whether suggested patches survive human review. That is the product OpenAI described on March 16.