There is a bug in FFmpeg's H.264 decoder that lived for sixteen years. It sat in code that ships on billions of devices, that human reviewers read, that every fuzzer worth running has hammered for over a decade. None of them found it. An AI model reading the source did.
That single fact is worth sitting with, because it breaks the mental model most of us carry about static analysis. We tend to assume the scanner already knows everything a bug could look like, and the only question is whether it bothered to check your file. The FFmpeg bug says something else: there is an entire class of vulnerability that our tools are structurally incapable of seeing, no matter how long they run.
The thing a pattern can't see
Traditional SAST works by matching. It carries a catalog of known-bad shapes — a tainted value reaching a SQL string, a call to a broken cipher, a hardcoded credential — and it walks your syntax tree looking for those shapes. This is genuinely useful, and I would never turn it off. It catches exposed passwords, outdated encryption, and the injection sinks that have signatures, cheaply and deterministically on every commit.
But notice what a signature requires: someone had to know the bug class in advance and write a rule for it. That works for vulnerabilities that live in the syntax. It falls apart for vulnerabilities that live in the meaning.
Consider a broken access-control bug. The code is syntactically flawless. There is no dangerous function call, no unsanitized sink, no pattern to match. The flaw is that an endpoint checks whether you're authenticated but forgets to check whether the resource is yours. Anthropic's framing of the gap is exact: these are "flaws in business logic or broken access control" — the mismatch between what the code does and what the specification requires. No regex describes that. A scanner that only matches patterns is grep with extra steps, and grep was never going to find it.
What "reasoning over code" actually means
The shift is that the model doesn't scan for shapes; it reads. Anthropic describes Claude as reasoning about code "the way a human security researcher would: understanding how components interact, tracing how data moves through your application." That's the whole trick. A researcher finding an authz bug doesn't pattern-match — they build a mental model of who is allowed to do what, then look for a path that violates it.
The more capable versions go a step further and close the loop that static analysis never could. In Anthropic's research, the agentic system doesn't just flag a suspicion — it "reads the code to hypothesize vulnerabilities, run[s] the actual project to confirm or reject suspicions," attaching a debugger and adding instrumentation as it goes. That is the difference between a tool that says "this might be exploitable" and one that produces a crashing input. Running Claude Opus 4.6, the team found over 500 vulnerabilities in production open-source codebases — bugs that had gone undetected for decades despite years of expert review. The research preview pushed further still, surfacing a 27-year-old flaw in OpenBSD's TCP stack and a 17-year-old remote-code-execution path in FreeBSD's NFS. These were not exotic corners. They were the most-audited code we have.
The false-positive tax, inverted
Every engineer who has been burned by a "smart" scanner is now bracing for noise, and rightly so. A tool that reasons more freely is a tool that can be confidently wrong more often. The interesting design choice is what happens after a finding is generated.
Instead of dumping every hypothesis on you, the review runs a multi-stage verification: "Claude re-examines each result, attempting to prove or disprove its own findings and filter out false positives." The same reasoning that generates a suspicion is turned adversarially against it. Findings that survive arrive with a severity and a confidence rating, plus the explanation of why it's exploitable — which is what lets a human adjudicate in seconds instead of reverse-engineering the tool's intent. The GitHub Action goes further and scopes analysis to the diff, so a pull request is reviewed for what it changed rather than re-litigating the whole tree on every push.
Wiring it into a pipeline
None of this requires a platform migration. The open-source Action drops into an existing workflow and comments on the specific lines it flags:
name: Security Review
permissions:
pull-requests: write # to leave inline findings
contents: read
on: pull_request
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha || github.sha }}
fetch-depth: 2 # enough history to diff against the base
- uses: anthropics/claude-code-security-review@main
with:
comment-pr: true
claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
The fetch-depth: 2 matters — the review is diff-aware, so it needs the parent commit to know what actually changed. Point it at pull requests, keep your existing SAST for the deterministic, cheap-to-verify classes, and let the semantic pass cover the logic and authorization bugs the pattern matchers can't reach.
The catch nobody gets to skip
Here is the part that should keep you honest: the capability is symmetric. A system that can trace data flow to find an auth bypass can trace it to weaponize one. Anthropic was blunt that its strongest model exceeds "the capabilities of all but the most skilled humans" at finding and exploiting vulnerabilities — which is why the strongest version isn't broadly released and instead runs through a restricted defensive program with a handful of critical-infrastructure partners.
The takeaway isn't "buy the tool." It's that the floor moved for both sides. The decades-old bugs in OpenBSD and FFmpeg were safe only because finding them cost more attention than anyone would spend. That economics just changed, and it changed for attackers too.
If a vulnerability's only protection was that it was too boring for a human to find, it is not protected anymore.
So stop treating AI review as a fancier linter. A linter enforces style; this is a second reviewer who will trace every data path through your access-control logic without getting bored, and who can prove the bug before it reaches your inbox. Wire it into the pull request, scope it to the diff, keep a human on the sign-off, and spend your reviewers' attention on the findings that already come with a working proof. The bugs that hid in meaning instead of syntax were never going to show up in a scan report. Now they don't have to.
Sources: Making frontier cybersecurity capabilities available to defenders (Anthropic), Assessing Claude Mythos Preview's cybersecurity capabilities (Anthropic), anthropics/claude-code-security-review (GitHub)