OpenAI Open-Sourced Codex Security, Not Its Brain

OpenAI open-sourced the CLI and TypeScript SDK for its agentic vulnerability scanner Codex Security on July 28 under Apache-2.0, but every scan still runs on OpenAI's hosted models authenticated via an OpenAI account or API key. The tool, which emerged from a private beta as Aardvark and scanned 1.2 million commits in 30 days finding 792 critical and 10,561 high-severity issues, is now available via npm install @openai/codex-security. OpenAI's Mariana Souza noted that the open-source release covers only the orchestration harness, not the model performing threat modeling and exploit reasoning.

AI https://sourcefeed.dev/c/ai Article OpenAI Open-Sourced Codex Security, Not Its Brain The Apache-2.0 CLI drops agentic vulnerability scanning into any pipeline, with OpenAI's hosted models doing the thinking. Mariana Souza https://sourcefeed.dev/u/mariana souza OpenAI pushed codex-security https://github.com/openai/codex-security to GitHub on July 28: an Apache-2.0 CLI and TypeScript SDK for the vulnerability-hunting agent formerly known as Aardvark. Hacker News promptly front-paged it as "OpenAI just open-sourced Codex Security," and that's true — with an asterisk large enough to change what you should do about it. What's open is the harness. Every scan still runs on OpenAI's hosted models, authenticated against your OpenAI account or API key. That distinction matters, because the interesting question isn't whether the code is on GitHub. It's whether agentic security scanning is ready to sit in your pipeline next to Semgrep — and what it costs you, in dollars and in data, to put it there. From private beta to npm install in nine months Codex Security has moved fast. It surfaced in late 2025 as Aardvark, a private-beta "agentic security researcher" that reads code, builds a threat model, and tries to actually exploit candidate bugs in a sandbox before reporting them. In March 2026 OpenAI renamed it and opened a research preview https://openai.com/index/codex-security-now-in-research-preview/ through Codex Web for ChatGPT Pro, Enterprise, Business, and Edu customers. The numbers OpenAI published from the beta were striking: 1.2 million commits scanned in 30 days, yielding 792 critical and 10,561 high-severity findings, including real vulnerabilities in OpenSSH, GnuTLS, PHP, and Chromium. Critical issues showed up in fewer than 0.1% of commits — which is OpenAI's way of saying the agent mostly stays quiet, the historic failure mode of every SAST tool ever shipped. Until this week, the CLI and SDK were gated behind "approved customers and partners" — OpenAI's own docs still said so when the repo went public, which tells you how quickly this release moved. Now it's npm install @openai/codex-security , sign in or set OPENAI API KEY , and go. What's actually in the repo This is a genuinely complete tool, not a demo. The workflow looks like: npx codex-security login npx codex-security scan /path/to/repo --fail-on-severity high npx codex-security validate sandbox-test candidate findings npx codex-security patch generate candidate fixes Beyond the basics there's diff-based scanning against a branch, SARIF/CSV/JSON export, a scans compare command that tracks new, persisting, and resolved findings across runs, a pre-commit hook installer, bulk scanning across GitHub org repos, Docker images with a hardened sandbox, and MCP integration so other agents can drive it. You can feed it threat-model context as Markdown, PDF, or Word docs via --knowledge-base — a quiet acknowledgment that repo contents alone don't tell you what an attacker cares about. Per the README, scans default to a top-tier reasoning configuration gpt-5.6-sol at extra-high effort , and it shows in latency: this is a minutes-per-scan deep-review tool, not a linter. The SARIF export and exit-code policy 1 on policy violation are the tell that OpenAI wants this in CI. That's the right ambition and the wrong first move — more on that below. The asterisk Calling this "open source" is accurate the way calling a thin client open source is accurate. The Apache-2.0 license covers the orchestration: prompt scaffolding, sandbox plumbing, output formats. The capability — the model doing the threat modeling and exploit reasoning — remains a hosted API you meter against. You can't self-host it, can't pin it, can't diff what changed when detection behavior shifts under you. Early HN reports of auth failures and content-policy refusals mid-scan "you are trying to do stuff we don't allow" underline the point: your security scanner now has an opinion about what it will look at, and you don't control it. This is the same play as the Codex CLI: open-source the distribution surface, keep the moat behind the API. It's a rational strategy, and it's also why the "free, extensible tool" framing making the rounds oversells it. Extensible, yes. Free, no — you're paying per scan at maximum-reasoning token rates, and for a large monorepo on every PR that adds up fast, nondeterministically. There's also a governance question that deterministic SAST never raised: every scan ships your source to OpenAI. For open-source maintainers that's a shrug. For anyone with contractual data-handling obligations, it's a legal review before it's a pipeline stage. Where it actually fits The competitive context makes this release look less like generosity and more like a land grab. Capital One open-sourced VulnHunter https://www.capitalone.com/tech/open-source/announcing-vulnhunter/ , its own agentic code-security tool, eleven days earlier. Anthropic ships a security-review command in Claude Code. Google's Project Zero has Big Sleep finding real CVEs. The agentic-scanner category is commoditizing at the interface layer while everyone bets the differentiation lives in the model — and OpenAI's beta numbers are the strongest public evidence so far that it does. What none of these tools do is replace your existing stack. Semgrep https://semgrep.dev/ and friends are deterministic, fast, cheap, and auditable — properties a merge-blocking CI gate needs and an LLM agent structurally lacks. And as runtime-security folks correctly point out, repo-only analysis can't see deployment misconfigurations, broken object-level authorization, or whether a vulnerable path is even reachable behind your auth layer. The validation sandbox cuts false positives; it doesn't conjure your production environment. The pragmatic adoption path: keep deterministic SAST as the gate, run Codex Security as a scheduled deep scan — nightly on main, or weekly across the org via bulk-scan — and use scans compare to triage only what's new. Treat patch output like any other AI-generated diff: a head start on a fix, reviewed by someone who understands the bug. Nine months from private beta to a public npm package is remarkable velocity, and the tool is real. Just be clear-eyed about what got open-sourced: the steering wheel, not the engine. If OpenAI raises prices, tightens refusals, or deprecates the model your baseline was built on, your "open" security tooling moves with it. Adopt it as a second layer with that dependency priced in, and it's one of the most capable additions to the AppSec toolbox this year. Sources & further reading - openai/codex-security https://github.com/openai/codex-security — github.com - OpenAI just open-sourced Codex Security https://news.ycombinator.com/item?id=49089755 — news.ycombinator.com - Codex Security: now in research preview https://openai.com/index/codex-security-now-in-research-preview/ — openai.com - OpenAI joins the race in AI-assisted code security https://www.helpnetsecurity.com/2026/03/09/openai-codex-security%E2%81%A0-feature/ — helpnetsecurity.com - Codex Security: What It Does Well and Where DAST Still Matters https://www.stackhawk.com/blog/codex-security/ — stackhawk.com - Announcing VulnHunter https://www.capitalone.com/tech/open-source/announcing-vulnhunter/ — capitalone.com Mariana Souza https://sourcefeed.dev/u/mariana souza · Senior Editor Mariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon. Discussion 3 yeah but what's the actual token burn per scan? if this is doing multi-turn reasoning over your codebase, that's going to crater your api budget the moment you run it on every pr. and nobody's talking about whether the model can even handle large repos without context window thrashing. honestly i'm curious too but i think there's a flip side — if the model's doing real reasoning work instead of just pattern matching, maybe the cost per scan is worth it compared to running twenty different static analyzers that each miss different stuff. like sure it might be expensive, but what's the actual dollar amount we're talking about before we write it off? feels like everyone jumps to "crater your budget" without doing the math. token math is brutal here—ran it on a medium monorepo, hit context limits fast, ended up paying $40/scan. semgrep's still free and doesn't hallucinate security findings.