Back to BlogFYEO News

    Claude Code Security: What It Actually Is (And the Verification Problem Nobody's Talking About)

    FYEOMarch 3, 2026
    Claude Code Security: What It Actually Is (And the Verification Problem Nobody's Talking About)

    What It Actually Is (And the Verification Problem Nobody's Talking About)

    Last week Anthropic launched Claude Code Security and wiped $20B+ off cybersecurity stocks in two days. CrowdStrike dropped 18%. IBM had its biggest single-day fall since 2000.

    The market panic is understandable. But having dug into the open-source code behind it, we think the real conversation is being missed.

    What is Claude Code Security?

    Strip away the marketing and here's what's happening under the hood.

    The entire "scanner" is a set of prompts sent to Anthropic's Opus 4.6 model. The code is open source on GitHub (anthropics/claude-code-security-review). Anyone can read it. And when you do, you find something surprising.

    The core detection prompt in prompts.py is essentially:

    "You are a senior security engineer conducting a focused security review of GitHub PR #[number]: [title]"

    "Perform a security-focused code review to identify HIGH-CONFIDENCE security vulnerabilities that could have real exploitation potential."

    It then provides a checklist of vulnerability categories — injection, auth flaws, XSS, hardcoded secrets, crypto issues — and a list of what NOT to report: DoS, rate limiting, open redirects, "lack of input validation on non-security-critical fields."

    The instruction ends with: "Focus on HIGH and MEDIUM findings only. Better to miss some theoretical issues than flood the report with false positives."

    That's the scanner. A role prompt, a checklist, and a confidence threshold.

    The false positive filter? It sends each finding back to the Claude API, asks the same model to score its confidence, and drops anything below 8 out of 10.

    There is no:

    Custom-trained security model.

    No specialised vulnerability detection neural network. 

    No static analysis engine. 

    No call-tree analysis. 

    No threat modelling. 

    It's a general-purpose LLM guided by a generic checklist prompt.

    To be clear: this works better than you'd expect. Opus 4.6 is genuinely good at reasoning about code, and Anthropic claims it found 500+ high-severity vulnerabilities in production open-source projects that had gone undetected for decades. That's impressive, and it's a meaningful step for defenders.

    But there's a fundamental problem with the verification architecture.

    The self-grading problem

    Claude Code Security's "adversarial verification pass" — the feature Anthropic highlights as reducing false positives — is the same model reviewing its own work.

    Opus 4.6 finds the vulnerability. Then Opus 4.6 checks whether the vulnerability is real.

    This is marking your own homework. And recent research quantifies exactly why that's a problem. This is known to lead to bias. (See references)

    Generic prompts, generic limitations

    Look at what the prompt actually asks for. It's a flat checklist: "Injection Attacks, Authentication & Authorization, Data Exposure, Cryptographic Issues, Input Validation, Business Logic Flaws, Configuration Security, Supply Chain, Code Execution, Cross-Site Scripting."

    • What it doesn't ask:

    • 1. What is this application's threat model? Who are the threat actors? What are the trust boundaries?

    • 2. What framework is this built on, and what does that framework already handle? (Express.js with helmet? Django with CSRF middleware? React with built-in XSS escaping?)

    • 3. What does the deployment architecture look like? Is this behind a WAF? Is the database on a private network?

    • 4. What do the call trees actually show? Where does tainted data flow across file boundaries?

    • A human security researcher doesn't walk into an audit with a generic checklist. They understand the system. They map the attack surface. They trace data flows through the specific architecture. They know that a raw SQL query behind three layers of input validation and a parameterised ORM is very different from one exposed directly to user input.

    • The prompt tells Claude to "reason about code the way a human security researcher would." But it then gives it none of the contextual framework a human researcher would build before writing a single finding.

    • The CASTLE benchmark study (2025) confirms this gap: LLMs performed strongly on small, self-contained code snippets, but "their accuracy declines and hallucinations increase as the code size grows." Real-world codebases are not small snippets. They're hundreds of files with cross-cutting concerns, framework conventions, and deployment contexts that a generic prompt can't capture.

    What actually works 

    The research consistently points in the same direction: hybrid approaches outperform pure LLM approaches.

    The InfoWorld/Virelya framework combining Semgrep with a fine-tuned Llama 3 achieved 89.5% precision — vs. 65.5% for GPT-4 alone and 35.7% for Semgrep alone. A 91% reduction in false positives compared to standalone SAST.

    IRIS (ICLR 2025) combined LLMs with static analysis for whole-repository taint tracking and found 4 previously unknown vulnerabilities that neither approach found alone.

    The pattern is clear: deterministic analysis provides the structural backbone (call trees, data flow, taint tracking), and LLM reasoning provides the contextual judgment. Independent verification — using a different model, a different approach, or ideally both — catches what self-review misses.

    This is something FYEO addresses in our tooling for our clients. 

    The Hybrid Approach

    Don't throw out your manual audit firm just yet…

    Claude Code Security is a genuine advance. AI-powered code scanning is clearly the future, and having it available to defenders is a net positive for everyone.

    But if you're a CISO or builder and  watching the stock ticker and wondering whether this replaces your security programme, take a breath.

    A tool that uses generic prompts, has no awareness of your threat model, sends your source code to a third-party API, and validates its own findings with the same model that generated them is not a replacement for expert security review. It's a useful triage layer. It's a good first pass. It will catch the low-hanging fruit faster than any human can.

    But for the vulnerabilities that actually matter — the business logic flaws, the subtle auth bypasses, the architectural weaknesses that only become visible when you understand the whole system. For this you need an AI / Human hybrid approach. And you need verification that's genuinely independent.

    Thomas is CTO of FYEO inc.

    References

    1. Tsui et al. (2025) — "Self-Correction Bench" https://arxiv.org/abs/2507.02778 The core finding: LLMs fail to correct errors in their own output while successfully correcting identical errors from external sources. 64.5% blind spot rate across 14 models. 

    2. Zhang et al. (2023) — "How Language Model Hallucinations Can Snowball" https://arxiv.org/abs/2305.13534 Explains the mechanism: once an LLM commits to an incorrect token, subsequent reasoning aligns with that mistake. This is why self-review fails.