OpenAI Just Open-Sourced a Security Scanner. Snyk and Semgrep Should Be Worried.

The scariest sentence in developer tooling is “OpenAI open-sourced that.” This week it landed on application security: OpenAI released a Codex-based scanner that reads your code, finds vulnerabilities, and proposes patches. What used to cost a per-seat SaaS license now runs from a CLI. And the fallout isn’t limited to the vendors — it raises a harder question nobody has a good answer to: who verifies a vulnerability report that a model wrote?

One caveat up front. There’s almost no community signal on this yet — thirty days of Reddit threads on the topic amount to roughly nothing. So this isn’t a read on sentiment. It’s a read on structure. But the silence is itself informative. Security tooling isn’t the kind of thing developers rave about on X. It’s the kind of thing you wire into CI once and never think about again. Low buzz, high blast radius.

What an AI Scanner Actually Does Differently

Static analysis has mostly been pattern matching. Semgrep is the canonical example: a human writes a rule saying “code shaped like this is an SQL injection risk,” and the tool sweeps the codebase looking for that shape. Fast, deterministic, boring in the good way. Scan the same file a hundred times, get the same hundred answers.

Snyk attacked a different axis. It walks your dependency tree and tells you that somewhere four levels down, a transitive dependency carries a known CVE. That’s fundamentally a database lookup problem. The moat was curation — how well you maintain the vulnerability DB.

An AI scanner is a third axis. It reads for meaning. Even with no matching rule, it can follow the context and see that this function takes user input and passes it, unvalidated, into a file path. Vulnerabilities spread across multiple files. Business logic flaws. Auth bypass paths. The category of bug that’s genuinely hard to express as a rule. And then it writes the fix.

Why the Market Wobbles Now

The AppSec business model was clean. The rule set was the asset. Years of accumulated detection rules, a curated CVE database, tuning know-how that beat down false positives. Package it, sell it at tens to hundreds of dollars per developer seat per year.

If a model can read code and reason about vulnerabilities directly, that moat gets shallow. If the model ships open source, the barrier to entry stops existing. What’s left to differentiate on: enterprise policy management, audit logs and compliance reporting for regulated industries, and the operational muscle to run scans across tens of thousands of repos. All genuinely valuable. All squarely “surrounding infrastructure” rather than “core technology.”

This is a familiar arc. It happened to code completion. It happened to document search. The moment a model gets good at the core capability, the capability commoditizes and the incumbents get pushed toward workflow and governance. That’s not a bad place to sit. The margins are just different.

How Much Should You Trust an AI-Generated Vulnerability Report

This is the real problem, and open source is already living through it. The maintainers of curl have gone public about AI-generated bogus vulnerability reports making their bug bounty program nearly unworkable. Plausible prose. Plausible CVE formatting. Plausible code citations. And no actual vulnerability underneath any of it.

False positives from an AI scanner are a different animal than false positives from static analysis. When Semgrep misfires, you look at the rule, think “yeah, that’s matching too broadly,” and move on. The cause is visible. When a model misfires, the explanation is coherent enough to cost you an hour. The paragraph describing the flaw hangs together logically. You cannot tell it’s wrong until you trace the code yourself.

Determinism breaks too. Scan the same commit twice, get two different result sets — now what does your CI gate on? A build that passed yesterday and fails today, with no code change between them, is the single fastest way to teach a team to ignore a warning channel entirely.

Auto-Patching Might Be the More Dangerous Half

“Finds it and fixes it” sounds great. But a security patch isn’t a normal bug fix. Fix it wrong and the vulnerability doesn’t disappear — it relocates. Add input validation that can be bypassed and the team now believes that surface is handled. That is strictly worse than having done nothing, because the false confidence blocks anyone from looking again.

The combination to actually fear: an AI finds the vulnerability, an AI writes the patch, and an AI code reviewer approves it. No human enters the loop at any point. Every individual step looks reasonable. The end-to-end result was never verified by anything that can be held accountable. The more frictionless the tooling, the more naturally work flows down exactly this path.

The pragmatic posture is to treat an AI scanner as a prioritizer, not a gate. Let it order the queue humans review. Don’t let it fail builds. Leave the deterministic rule-based tools exactly where determinism is required. And for anything claimed to be a real vulnerability, demand reproducible evidence — a runnable proof of concept, not a well-written paragraph.

Who Actually Wins Here

The biggest beneficiaries are small teams with no security function. Plenty of shops today run zero static analysis, not because they decided against it but because nobody would approve the license spend. For them, free plus local plus context-aware is a zero-to-one change. A 30% false positive rate still beats scanning nothing.

For organizations with mature security programs, this is more likely to be additional noise. They already have rule-based tooling in the pipeline, a triage process, and a named owner. Bolting on another signal source with a high verification cost isn’t obviously net positive. That math has to be done, not assumed.

And there’s a beneficiary nobody puts on the slide: attackers. Vulnerability discovery tooling is perfectly symmetric — defenders and attackers run the same scanner. Sweeping large swaths of open source looking for bugs nobody has reported yet just got dramatically cheaper. The rate at which patches ship and the rate at which exploits ship are now both accelerating. That’s a race, not a win.

The Takeaway

The value in security tooling is migrating from “can you find vulnerabilities” to “can you tell which findings are real.” Finding just got cheap. Verification didn’t. That’s where the next generation of defensible product gets built.

So the question for your team is narrow and consequential: does this run as a blocking CI gate, or strictly as a sort order for a human review queue? Whichever way you answer, you’re setting your team’s security culture for the next several years — and the tooling will not make that call for you.