OpenAI's codex-security repository sat near the top of Hacker News this morning with several hundred points, and the README makes it look like a five-minute install: npx codex-security scan ., Apache-2.0, Node 22 and Python 3.10 or newer, sign in with ChatGPT or set OPENAI_API_KEY. Then you read OpenAI's own documentation and find the catch. The CLI and SDK are "in limited beta and available only to approved customers and partners," the cloud product is a research preview, and no price is published. Open source, closed door.
That is worth knowing before you spend an afternoon on it. It is also worth understanding what the tool is trying to do differently, because that idea is the useful part, and then spending the afternoon on something you can actually install.
The idea inside the gate
Per OpenAI's documentation, Codex Security scans repositories "commit by commit" and "builds scan context from your repo, checks likely vulnerabilities against that context, and validates high-signal issues in an isolated environment before surfacing them." The claim that matters there is the last clause: a validation step that tries to reproduce a finding before it reaches you.
Anyone who has run a scanner on a real codebase knows why that is the interesting bit. The bottleneck in small-team security is not detection, it is triage. A first scan on a modest application will hand you dozens of findings, most of which are unreachable code paths, test fixtures or framework behaviour the scanner does not model. The cost is the hour you spend proving that. It is the same constraint we described from the other direction in review capacity is the new limit: generation is cheap now, and the human read is what is scarce.
What you can install today
Methodology for the table: every figure is a list price or published limit taken from the vendor's own pricing or billing page, opened on 29 July 2026. Free-tier ceilings are the deciding variable for teams under about ten people, so they are the first column, not a footnote. Where a vendor does not publish a price on the pages we opened, the cell says so rather than repeating a number from elsewhere.
| Free tier | Paid entry price | Counting unit | |
|---|---|---|---|
| Semgrep | $0, up to 10 contributors and 10 private repos, includes Code (SAST) and Supply Chain (SCA), cross-file analysis, Pro rules, 60 AI credits | Teams from $30 per contributor per month (Code $30, Supply Chain $30, Secrets $15), up to 500 private repos | Contributor |
| Snyk | $0, 5 projects, monthly test caps: 200 Open Source, 100 Code, 300 IaC, 100 Container | Team from $25 per contributing developer per month, 1,000 tests a month, 100 projects. Ignite from $1,260 per developer per year | Contributing developer: committed to a monitored private repo in the last 90 days |
| GitHub | Code scanning, secret scanning, push protection, Dependabot and dependency review free on public repositories | Code Security and Secret Protection are add-ons for Team; no price shown on the pages we opened. Team itself is $4 per user per month for the first 12 months | Active committer: pushed a commit in the last 90 days, holding a Team or Enterprise licence |
| Codex Security | Not available: approved customers and partners only | Not published | Not published |
Sources: Semgrep pricing, Snyk plans, GitHub Advanced Security billing and GitHub pricing.
One correction to a widely repeated figure: several third-party sites quote a per-committer list price for GitHub Code Security. It is not on GitHub's pricing page or its Advanced Security billing documentation, both of which we opened, so we are not repeating it. Ask GitHub for the current number before you budget on it.
The cost arithmetic for a three-developer team
Our math, three developers, all committing to private repositories, one product:
- Semgrep Free: $0. Three contributors against a ten-contributor ceiling, and Code plus Supply Chain are both included. You would pay $0 until you hit either 10 contributors or 10 private repos.
- Snyk Free: $0, but the binding constraint is tests, not people. 100 Code tests a month across three developers is roughly one scan per developer per working day, which a pull-request hook will exhaust in the first week. Snyk Team at $25 per contributing developer is $75 a month for 1,000 tests.
- GitHub: $0 if your repositories are public. If they are private, code scanning is a paid add-on on top of Team at $4 per user per month, so budget the platform cost plus an unpublished add-on cost.
The pattern: for a small team on private repos, Semgrep's free tier is the only one of the three that covers both static analysis and dependency scanning without a per-seat charge, and its ceiling (10 contributors, 10 repos) is generous enough that most teams outgrow the company before they outgrow the plan. That is a statement about the current price lists, not about detection quality, which no pricing page can tell you.
The order to do this in
Scanning is the second job, not the first. Run it in this sequence and the findings arrive in an order you can act on:
- Secrets first, and on history. A live credential in a commit from 2023 is worth more to an attacker than any injection finding. GitHub's secret scanning and push protection are free on public repositories and catch the recurrence; the historical sweep is a separate job, and the failure mode we documented in a security camera that shipped a GitHub admin token was a build artefact, not a repo.
- Dependencies second. Supply chain findings come with a version number and a fix, which makes them the highest ratio of resolved risk to time spent. Both Semgrep Free and Snyk Free include this.
- Static analysis third, scoped to a diff. Run the full scan once to see the shape of the backlog, then wire the scanner to pull requests only. A full-repo scan on every push produces a number nobody reads; a diff scan produces three findings the author still has in their head.
- Your own exposed surface last, and by hand. No scanner reliably finds an endpoint that works exactly as written but should have required a login. That is a manual pass, and the five checks in the unauthenticated endpoint audit are the version to run.
A triage rule that keeps the backlog from winning
After the first full scan, sort by two questions rather than by severity label. Is the code path reachable from an unauthenticated request? Does the finding touch data belonging to someone other than the requester? Anything answering yes to both gets fixed this week. Anything answering yes to one gets a ticket. Everything else gets marked and reviewed monthly. Severity scores are computed without knowing your architecture; those two questions are not.
As for Codex Security: request access if you want it, and watch the validation claim specifically. A scanner that reproduces its own findings before showing them would change the economics of the triage step above more than any improvement in detection rate. Until the beta opens and someone publishes a false-positive rate measured against a known corpus, it is a promising design, not a tool you can plan around. Keeping your infrastructure choices boring while the category settles, as we argued in the boring stack, applies to security tooling too.
Discussion
Sign in with Google or just a name. No email link, no password to remember.