In this article
What just happened
OpenAI has open-sourced Codex Security — and this is not just one more tool that scans a few lines of code.
The most notable part: OpenAI is packaging an AppSec workflow modeled on an AI Security Researcher into a CLI and a TypeScript SDK, so developers can drop it straight into their local workflow, pre-commit, and CI/CD.
Put simply:
Traditional SAST tends to ask: "Does this code look like a dangerous pattern?"
Codex Security tries to ask: "In this system's actual architecture, which input can an attacker start from, which trust boundary can they cross, and what impact can they create?"
That is the difference between flagging a pattern and reasoning about an attack path.
What can Codex Security do?
The openai/codex-security repo provides:
- A CLI to scan an entire repository, a specific path, the working tree, or the diff against a base branch.
- A TypeScript SDK for embedding security scanning into an internal developer platform or your own automation.
- Knowledge base input: architecture documents, threat models, and security policies can be fed in as context.
- Machine-readable output including
findings.json,coverage.json, a Markdown report, and optional SARIF export. - A CI policy gate based on a severity threshold.
- A pre-commit hook to check changes before they are committed.
- Bulk scanning across multiple repositories, plus the ability to run in Docker with a hardened sandbox.
Quick start:
npm install @openai/codex-security
npx codex-security login
npx codex-security scan .
Current requirements: Node.js 22+, plus Python 3.10+ for scanning and export, and access to Codex Security. The package is early (0.1.1) and the public API may still change before 1.0.0.
Why does this open-sourcing matter?
1. Security review is becoming an agentic workflow
AI is no longer just commenting "this might be SQL injection." An agent can read the codebase, build a threat model, trace attack paths, gather evidence, attempt validation, and propose remediation.
The target workflow is:
Discover → Validate → Patch → Human Review → Revalidate
This is the direction that can actually take load off an AppSec team. The problem with security scanners has never been a shortage of alerts — it is too much alert noise and too little triage time.
2. Security context becomes part of the repo
If your organization already has:
architecture.md- a threat model
- data classification
- trust boundaries
- security policy
- authentication/authorization rules
then those documents are no longer just audit artifacts. They can become executable input for a security agent. This is exactly why a disciplined seven-part document set for an AI workflow pays off.
In other words: good documentation starts producing direct value inside the pipeline.
3. Developers can pull security closer to the moment code is written
Instead of waiting until the end of the sprint or a pentest right before release, a team can scan:
# Review changes against main
npx codex-security scan . \
--diff origin/main \
--json \
--fail-on-severity high
Or install a pre-commit check:
npx codex-security install-hook
Earlier detection means cheaper remediation — and fewer nights that go "we ship at 8pm, and at 5:30pm security files a Critical."
A practitioner's view: how would I roll this out?
Do not switch it on across the whole organization and then treat the AI's output as "security truth."
I would roll out in four steps:
Step 1 — Pilot on 1–2 repositories with moderate risk
Pick a service with reasonably good tests, a clear architecture, and a security owner who will review the results.
Step 2 — Standardize the context
Build a minimum security knowledge base covering:
- Entry points
- Trust boundaries
- Sensitive data
- The authentication/authorization model
- Which behaviors are allowed and which are not
- Areas where risk is accepted
Feed it the wrong context and the AI's reasoning will be extremely confident… and still wrong.
Step 3 — Run report-only first
Measure over 2–4 weeks:
- Finding precision
- False-positive rate
- Triage time
- Cost per scan
- Share of findings that get validated
- Share of patches that get accepted
Only then turn on --fail-on-severity high for diffs and PRs. The measurement, pilot, and governance discipline for AI projects applies here without modification.
Step 4 — Keep a human in the loop
Codex Security proposes patches; it does not automatically edit production code. That is the right design.
A security patch still has to go through:
- Code review
- Regression testing
- Security owner approval
- Revalidation after merge
But do not misread the word "open-source"
OpenAI open-sourced the CLI/SDK and the workflow layer, under the Apache 2.0 license.
That does not mean the underlying model has been open-sourced, that scanning is free and unlimited, or that every account can run a full-repository scan. The official documentation still labels the CLI/SDK as beta, requires access, and in some cases may require Trusted Access for Cyber.
Scan results can also contain source excerpts and vulnerability details. Do not write them carelessly into a workspace, a public artifact, or CI logs. Instead:
- Store output outside the repository.
- Use private artifact storage.
- Set a retention policy.
- Manage API keys with CI secrets or a secret manager.
- Only scan code you own or are authorized to assess.
These handling rules sit squarely inside the same obligations covered by data privacy and Vietnam's AI law in 2026.
Conclusion
openai/codex-security is not yet a reason to drop SAST, dependency scanning, secret scanning, DAST, or pentesting.
But it points in a very clear direction:
The future of DevSecOps is not more alerts.
The future is an agent with enough context to find the right risk, prove exploitability, and propose a patch a human can review.
For developers, the skill that matters next is not just "writing secure code," but designing the context, policy, and evaluation that let a security agent do its job correctly.
