Claude Code Security Can Now Find 0-days. Here's Why That Doesn't Replace SAST

On February 20, 2026, Anthropic launched Claude Code Security — a capability built into Claude Code that scans codebases for vulnerabilities and suggests patches for human review. The announcement was accompanied by a striking claim: using Claude Opus 4.6, Anthropic’s research team had found over 500 previously unknown, high-severity vulnerabilities in production open-source projects, including GhostScript, OpenSC, and CGIF. Bugs that had survived decades of expert review and fuzzing.

The market reacted within hours — cybersecurity stocks dropped across the board: CrowdStrike fell 8%, Cloudflare 8.1%, SailPoint 9.4%. The narrative was obvious: AI just made the AppSec industry obsolete.

But it’s not the time to worry, the reality is way more nuanced.

 

What Claude Code Security Actually Does

Claude Code Security represents a genuine leap in automated vulnerability discovery. Unlike traditional static analysis, which matches code against predefined rule sets, Claude reasons about code the way a human security researcher would: tracing data flows, understanding how components interact, and identifying context-dependent flaws that pattern matching structurally cannot reach.

As SOCRadar’s analysis notes, the tool’s strongest value lies in vulnerability classes like business logic flaws, broken authorization flows, authentication bypasses, and multi-step injection chains spanning multiple modules. In the CGIF library, Claude discovered a heap buffer overflow by reasoning about the LZW compression algorithm — something coverage-guided fuzzing couldn’t catch even with 100% code coverage.

For novel vulnerability discovery, the capability is a gem. The question is what changes and what not.

 

Novel Discovery vs. Known Pattern Coverage

Claude Code Security targets novel, context-dependent vulnerabilities — the kind that require understanding architectural intent and reasoning about how systems interact. Rule-based SAST targets known vulnerability patterns mapped to CWE, OWASP Top 10, and SANS/CWE Top 25 — what regulators, auditors, and compliance frameworks actually check for.

Anthropic themselves frame it clearly:

Claude Code Security “catches complex vulnerabilities that rule-based tools miss.”

Note the phrasing: “rule-based tools miss.” Claude fills that gap. But the statement also implicitly defines the space rule-based tools cover well — the known, catalogued, standards-mapped vulnerability patterns that form the baseline of any security program.

As Snyk’s response to the announcement put it: “Finding vulnerabilities has never been the hard part.” Systematic coverage, remediation at scale, and deterministic evidence that your code meets defined standards — classical SAST handles that.

 

The Hallucination Problem in a Security Context

Anthropic is transparent about a known limitation: AI can “hallucinate bugs” — flagging vulnerabilities that don’t actually exist. Claude Code Security mitigates this with a multi-stage verification process, confidence ratings for each finding, and mandatory human approval before any patch is applied.

In a security context, this distinction matters enormously. A false positive from a rule-based SAST tool is annoying — it takes time to triage. A false positive from an AI reasoning engine can be convincing — it comes wrapped in plausible context, architectural reasoning, and a suggested fix. Research has shown that running the same AI scan on the same code can produce different results, because the output is non-deterministic by nature.

Rule-based SAST findings are deterministic and reproducible. Run the same scan today and tomorrow, you get the same results. When your auditor asks “show me the evidence,” you need a scan report that produces identical output regardless of when you ran it.

 

Data Sovereignty: Where Your Code Goes

Claude Code Security on the web runs in Anthropic-managed isolated VMs. This means your source code is processed in Anthropic’s cloud infrastructure. Anthropic states they don’t train models on customer code, and the environments are automatically terminated after sessions end.

Many organizations will find that acceptable. Defense contractors, financial institutions with strict data residency requirements, healthcare organizations under HIPAA, government agencies, and teams in air-gapped environments may not. When your security policy prohibits source code from leaving the perimeter, the question shifts from capability to architecture.

On-premise and self-hosted SAST tools like DerScanner run entirely within your infrastructure. The code never leaves. For organizations in regulated industries, this is often not a preference.

 

Compliance Requires Deterministic Evidence

The EU Cyber Resilience Act (CRA), NIS2 Directive, DORA, and PCI DSS all require documented evidence that your software has been tested against known vulnerability standards. Auditors expect scan results mapped to specific CWE entries and OWASP categories, with reproducible findings they can verify independently.

AI-generated security reports with confidence ratings and reasoning-based findings are valuable for internal security improvement. But they don’t yet fit standard compliance workflows. An auditor reviewing your CRA compliance wants to see: “CWE-89: SQL Injection — detected in file X, line Y, confirmed by rescan.” Not: “Model confidence 87% that a potential injection path exists based on architectural reasoning.”

As SOCRadar emphasizes:

“Regulatory and compliance requirements still demand deterministic processes, documented controls, and auditability.”

Until compliance frameworks evolve to accommodate AI-generated findings, rule-based SAST remains the language auditors speak.

 

What Source-Level AI Doesn’t Cover

Claude Code Security operates at the source code level. But modern application security extends far beyond source analysis. Supply chain risks — compromised build artifacts, malicious dependencies, tampered CI/CD pipelines — bypass source-level scrutiny by design. SBOM validation, artifact integrity checks, and dependency monitoring require purpose-built tooling regardless of how capable the source analysis layer becomes.

SAST solutions like DerScanner cover 43 programming languages including legacy and rare ones (Delphi, Pascal, ABAP, Perl, COBOL) that AI models may not have sufficient training data to reason about reliably. When your codebase includes languages that fewer than 1% of developers actively use, pattern-based coverage with language-specific rule sets remains the only viable approach.

And then there’s the full AST picture: DAST (testing running applications), SCA (analyzing third-party components), MAST (mobile application security). AI reasoning about source code, however sophisticated, covers just one layer of a multi-layer security strategy.

 

The Answer Is Both

The clearest take on Claude Code Security came from Snyk’s analysis: the framing of “deterministic vs. probabilistic” misses the point. Each tool solves a different problem.

AI-powered reasoning handles novel vulnerability discovery. Rule-based SAST handles known pattern coverage, compliance evidence, and deterministic, reproducible results. They’re complementary.

The organizations that will be best protected are those that layer both: classical SAST as the foundation — covering known vulnerabilities, mapping to CWE/OWASP standards, providing audit-ready evidence, running on-premise where required — and AI-powered analysis as an augmentation for catching what rules can’t express.

Claude Code Security is an impressive capability that deserves adoption and integration into security workflows. Layer it on top of classical SAST — which still provides the known-pattern coverage, audit-ready evidence, and on-premise deployment that AI-based scanning cannot. The foundation has to be solid before you add the next floor.