OpenAI's Codex Security has been running as a research preview since March, and it's one of the more ambitious built-in security tools among the major AI coding platforms specifically because of how it's built: not a fixed list of patterns applied uniformly, but an attempt to model each codebase's own specific threat surface.
What "builds a threat model" actually means
Most automated scanners check a codebase against a fixed, known list of patterns: does this look like an exposed key, does this look like a missing access check. Codex Security is built to first understand what a specific codebase actually does, what data it handles, what its entry points are, and reason about that codebase's own particular risk surface, rather than applying the exact same checklist to every project regardless of what it is.
The reported numbers, and what they actually establish
Within its first 30 days in research preview, Codex Security had scanned roughly 1.2 million commits and flagged around 800 critical and over 10,000 high-severity issues, by OpenAI's own reported figures. That's a genuinely large scale of scanning activity. It establishes that the tool is actively being used and actively finding things worth flagging. It doesn't, on its own, establish what fraction of real, exploitable vulnerabilities across those codebases it actually caught, since there's no independent count of what was present to compare against.
The Daybreak initiative context
Codex Security sits at the center of OpenAI's broader "Daybreak" cybersecurity initiative, and has since picked up integrations extending beyond its original scope, including a GitLab integration in beta, following its initial GitHub-focused rollout. That expansion pattern, a security tool built for one platform extending to a second, is becoming a common shape across this space, and it's a reasonable signal that this kind of scanning is being treated as infrastructure rather than a one-platform perk.
What a codebase-aware tool still can't verify
- Your live production database's actual access rules, since that's a runtime configuration question, not something visible from reading code.
- Whether a third-party service you've connected is itself configured correctly on its own end, outside of anything in your own repository.
- What your app actually exposes to an outside visitor right now, since a code-level tool reasons about the code as written, not about your live, deployed surface.
- Business logic correctness beyond what it can infer from the code and any accompanying context, which is a genuinely hard problem even for a tool built to reason about a specific codebase's intent.
The honest read
Building a tool that reasons about a specific codebase's own risk surface, rather than one generic rule set for everyone, is a meaningfully more ambitious approach than most built-in scanners attempt, and worth genuine credit for the direction. It's still a code-level, build-time tool. Whether your specific app, as actually deployed, exposes something to a stranger right now is a different question, one that has to be answered by actually checking the live, running app, not by reasoning about its source.
Related reading
- OpenAI's Security Scanner Just Followed Developers to GitLab, and That's the Interesting Part
- Every AI Coding Tool Added Security Checks This Year. Here's What They Still Leave Out.
- What Claude Code's Built-In Security Review Actually Catches
Built with Codex? See what your live app exposes from the outside too.
Scan my app free