Artemiy Malyshau· Co-founder & CTO12 min readFinding vulnerabilities in code has never been the hard part. Knowing which ones are exploitable in your specific system is what breaks security teams. And it’s exactly what every code scanner, including Claude Code Review and Claude Code Security, cannot tell you.
Both products read source files. Neither has visibility into your deployment, your trust model, or your infrastructure. A buffer overflow behind two layers of internal auth is a different risk than the same bug on a public endpoint. Code alone doesn’t contain that information. Your trust model lives in architecture documents. Your deployment topology lives in infrastructure config. Your business logic lives in design specs and risk registers. When a scanner only reads source files, it has no way to distinguish a genuine exploit path from a theoretical finding that your infrastructure already neutralizes.
AI coding assistants made this gap worse. Code output per developer jumped 200 percent while security review capacity stayed flat. The result: more findings, lower signal, and no reliable way to know what to fix first.
TLDR:
March 2026 changed how developers think about AI in their workflow. Anthropic shipped a series of updates to Claude Code that moved it from experimental assistant to production tool: push-to-talk voice mode, recurring tasks via /loop commands, a 1 million token context window, and Opus 4.6 as the default model. These weren’t incremental improvements. They expanded what Claude could handle in a single session.
Two distinct security products shipped in this window. Claude Code Security arrived in February as a standalone vulnerability scanner for codebases. Claude Code Review followed on March 9th as a research preview focused on pull request analysis. They share the Claude Code name but solve different problems at different points in the development workflow.
Claude Code Review is a PR-level tool. When you open a pull request, the system spins up five independent reviewer agents. Each one analyzes your changes from a different angle: one checks CLAUDE.md compliance, another hunts for bugs, a third reviews git history for context, the fourth looks at previous PR comments, and the fifth verifies code comments match implementation. Every finding gets scored on a 0-100 confidence scale. Only issues above 80 make it into your PR as comments.
This multi-agent architecture mimics how human reviewers approach code. You don’t just read the diff line by line. You check if it follows team conventions, look for patterns that caused bugs before, and verify the code does what the comments claim. Claude Code Review automates that process without requiring configuration files or custom rules.
What it doesn’t do: analyze your deployment architecture, understand your trust model, or reason about whether a finding is actually exploitable in your specific system. It reads the diff. That’s the boundary of its visibility.
The five parallel agents working on each pull request don’t share context during analysis. Each one runs independently, building its own understanding of the code before surfacing findings. This isolation prevents confirmation bias, where one agent’s conclusion influences another’s reasoning. The bug-hunting agent might flag a potential race condition while the compliance agent completely ignores it in favor of style violations.
The scoring mechanism filters noise at scale. Every finding includes a confidence score, and the 80-point threshold acts as a gate. Lower-confidence observations get logged but never reach developers. This is how Claude Code Review achieves a false positive rate below 1%, eliminating the core failure mode that made earlier automated tools unusable.
For large changes exceeding 1,000 lines, the system flags problems in 84% of cases, averaging 7.5 issues per pull request. That detection rate reflects reasoning about code behavior, not syntax matching, though some vulnerabilities require deeper approaches like Gecko’s 30 0-day discoveries other tools missed.
Claude Code Security launched in February 2026 with a striking claim: Anthropic’s team found over 500 vulnerabilities in production open-source codebases using Claude Opus 4.6. These weren’t surface-level issues. They were bugs that survived decades of expert review and automated scanning.
That’s a genuine improvement over traditional static analysis. Pattern-based tools know what insecure code looks like and flag anything that fits the template: hardcoded API keys, weak crypto algorithms, SQL concatenation instead of parameterized queries. Claude Code Security goes further by reasoning over code to understand intent, then checking if the implementation enforces it. When authorization logic appears inconsistent across endpoints, or when user input flows to sensitive operations without validation between service boundaries, the model flags it based on what the code should do, not solely on what it looks like. That’s why static analysis struggles with business logic while Claude Code Security finds bugs that pattern matchers miss.
But reasoning over code still has a hard ceiling. Claude Code Security only reads source files. It has no visibility into your deployment, your infrastructure, or your trust model. That boundary creates a problem it cannot solve: it cannot tell whether a finding is a bug or an intentional feature. A function that skips an authorization check might be a critical vulnerability, or it might be a deliberate exemption for internal service calls behind two layers of authentication. The code doesn’t say. And Claude Code Security has no way to find out.
The risk classification problem is just as serious. A buffer overflow on a public API endpoint is a different threat than the same bug in an internal admin tool accessible only to three people on your ops team. Knowing which one to fix first requires understanding your deployment topology, your trust boundaries, and your actual exposure surface. That information doesn’t live in source files. It lives in architecture documents, infrastructure config, design specs, and risk registers. Claude Code Security has access to none of it.
There’s also a parsing accuracy problem that limits production use. Code reasoning models perform best on statically typed languages where intent is explicit. Dynamically typed languages introduce ambiguity that no model fully resolves at the inference layer. The result is findings that require manual triage to separate real issues from noise.
Viewed clearly, Claude Code Security is a strong demonstration of how capable foundation models have become at reasoning over code. As an enterprise security product, it’s limited by the same constraint as every code-only scanner: the source of truth about what actually matters in your system isn’t in the code.
AI coding assistants accelerated code output without changing how teams review that code. At Anthropic, code output per developer jumped 200 percent in a single year. More pull requests, larger changesets, and the same number of security engineers reviewing them.
The numbers from March 2026 research were stark: across 38 scans covering 30 pull requests from Claude Code, OpenAI Codex, and Google Gemini, agents produced 143 security issues. That’s an 87 percent vulnerability rate, with 26 of those PRs containing at least one security flaw.
The real problem isn’t that AI writes vulnerable code. It’s that AI writes vulnerable code that looks clean, passes tests, and ships with developer confidence. Human reviewers can’t triple their output to match AI-generated volume. The gap between what ships and what gets properly reviewed grows every sprint.
This is a structural limitation, not a tooling gap. No scanner that reads only code will ever accurately find business logic vulnerabilities, because the source of truth for what actually matters in your system is not in the code.
Business logic vulnerabilities are mismatches between what a developer intended and what the implementation actually does. That intent lives in design documents, architecture specs, threat models, and risk registers like bug bounty guides. It does not live in the diff. It does not live in the source file. And no amount of reasoning over code can reconstruct it, because the code only records what was built, not what was meant to be built.
Think about what code scanners cannot see. Your deployment architecture: whether a service is internal or publicly exposed, what sits in front of it, how many layers of auth a request passes through before reaching a vulnerable function. Your trust model: which callers are considered trusted, which token types carry which permissions, where privilege boundaries are drawn. Your business rules: which users should have access to which resources under which conditions, and which edge cases were deliberately handled differently. Your risk register: which findings your team already reviewed and accepted, which are behind mitigations your infrastructure provides.
A buffer overflow behind two layers of internal auth is a categorically different risk than the same bug on a public endpoint. A function that skips an authorization check might be a critical vulnerability or a deliberate exemption for internal service calls. Pattern-based scanners flag eval() or hardcoded secrets because the vulnerability exists entirely in the code. Authorization bugs like CVE-2025-51479 in ONYX’s group management API require knowing what should happen across your system, then checking if the implementation enforces it. That knowledge is not in any source file.
This is why code-only scanners produce findings that require extensive manual triage. They surface everything the code could theoretically do wrong, with no way to filter by what actually matters in your deployment. The result is a triage burden that grows with your codebase, not a ranked view of real risk.
Artemiy Malyshau
Co-founder & CTO
Artemiy served in an elite unit of the Austrian Cyber Forces, defending national infrastructure He was then the first employee at a government-backed cybersecurity research group, where he led security projects for Interpol and national governments. At Gecko he builds the platform trusted to sit inside Fortune 500 codebases, and holds it to the standard those governments taught him.
The latest news, technologies, and resources from our team.
How Cal.com consolidated noisy security tooling into one continuous, context-aware pull request security program with Gecko.
Gecko Security
Authorization bypass in n8n’s dynamic-credentials OAuth endpoints allows any authenticated user to operate on another user’s OAuth credential by supplying its ID, enabling unauthorized OAuth rebinding and revocation.
Artemiy Malyshau
An IDOR vulnerability in n8n’s public variables API allows authenticated users to read project variables outside their authorized scope, exposing secrets across project boundaries.
Artemiy Malyshau
Learn API scanning for automated security testing. Find vulnerabilities from broken authentication to business logic flaws in your endpoints.
Artemiy Malyshau
A complete guide to automated pentest tools and best practices. Learn what works, what doesn’t, and how to implement continuous security testing.
Artemiy Malyshau
Compare the best AI-powered application security testing tools. Find which tools detect business logic flaws and broken access control.
Artemiy Malyshau
Occasional updates, new content, and insights. No spam; unsubscribe anytime.
The code-review plugin ships in Anthropic’s official repository on GitHub. Inside Claude Code, open the plugin marketplace and search for “code-review” to install it. Once active, open any pull request and run /code-review in your command palette. The five parallel agents spin up automatically, analyze your diff, and post findings as PR comments within minutes.
The pr-review-toolkit takes a lighter approach, wrapping Claude’s API to review diffs without requiring the full Claude Code environment. Install it via npm and point it at your repository. It handles single-file reviews faster than the official plugin but skips the multi-agent scoring system and can’t catch issues like CVE-2025-51482 RCE via unsanitized tool execution. The hamelsmu/claude-review-loop plugin on GitHub adds iterative review cycles, where Claude re-analyzes code after you resolve initial feedback.
| Tool | Architecture | False Positive Rate | Detection Scope | Best Use Case |
|---|---|---|---|---|
| Claude Code Review | Five parallel independent agents with 80+ confidence scoring threshold. Reads diffs only, no infrastructure or deployment context | Sub-1% on PR-level changes | Style violations, documentation issues, and surface-level bugs within changed files. Cannot detect cross-service flaws or assess whether a finding is exploitable in your system. | High-volume PR workflows needing automated consistency checks without noise |
| Claude Code Security | Single-model reasoning over source files using Opus 4.6. Reads code only, no deployment or trust model visibility | Not independently measured; requires manual triage to separate real issues from noise, especially in dynamically typed codebases | Bugs that pattern matchers miss by reasoning over code intent. Cannot distinguish a genuine exploit path from a finding your infrastructure already neutralizes. | Baseline vulnerability scanning on statically typed codebases where deployment context is handled separately |
| GitHub Copilot | Single-model inline suggestions during code writing | Not measured for review context | Syntax errors, basic pattern matching, code completion | Real-time coding assistance for individual developers writing new code |
| OpenAI Codex | Single-model code generation and analysis | 87% vulnerability rate in generated code across 30 PRs tested | Code generation with basic linting, no specialized security focus | Rapid prototyping where security review happens separately downstream |
| Google Gemini | Single-model with multimodal capabilities | 87% vulnerability rate in generated code across 30 PRs tested | Code generation and explanation, limited security analysis | Code documentation and explanation tasks, not security review |
| pr-review-toolkit | Lightweight Claude API wrapper for single-file analysis | Not independently measured | Fast single-file reviews without multi-agent validation | Quick reviews on small changesets where speed matters more than depth |
| Gecko Security | Code analysis combined with design document ingestion, infrastructure context, and runtime data to align findings against actual business risk and deployment exposure | Around 20%. Lower false positives come from aligning findings against your deployment architecture and trust model, beyond proof-of-concept generation alone | Authorization bypasses, privilege escalation, and business logic flaws, ranked using context from design documents, infrastructure, and runtime data, going beyond code analysis alone | Finding vulnerabilities that genuinely matter in your system: cross-service logic flaws, missing authorization checks, and exploitable paths that code-only scanners surface but leave unranked |
Developer feedback shows Claude catches real issues with minimal noise, though it misses complex cross-service attack chains. The sub-1% false positive rate means PRs stay clean while surfacing legitimate problems around error handling, validation inconsistencies, and stale documentation.
The failures matter more. Logic bugs across services or business rule violations don’t register. Authorization checks split between repos or trust boundaries in microservices stay invisible because the review happens one file at a time. That architectural blind spot excludes the vulnerability classes that cause actual breaches.
Against GitHub Copilot and standard CI linting, Claude wins on explanation quality. Each finding includes reasoning that helps developers understand context, which turns code review into a learning tool instead of just another gate.
Claude Code Review works best for teams shipping 20+ pull requests weekly where review bottlenecks slow deployment. The economics make sense when senior engineers spend hours per PR on style consistency and documentation checks. Automating that frees them for architecture decisions and security design that AI can’t handle.
Small teams with five developers touching the same codebase don’t need it. You already know the context, and review happens through conversation. The overhead of checking AI-generated comments outweighs time saved.
Greenfield projects with clean patterns and consistent conventions play to Claude’s strengths. The model learns your team’s style from CLAUDE.md and previous reviews, then enforces it automatically. Legacy codebases with inconsistent patterns across services confuse the agents and may harbor vulnerabilities like CVE-2025-51458 SQL injection via CVE bypass. They flag violations that are actually intentional deviations from outdated standards.
Skip it entirely if your vulnerabilities live across service boundaries or in business logic between systems.
The hard part of application security was never finding vulnerabilities in code. It’s knowing which ones actually matter in your system.
Code scanners, including Claude Code Review and Claude Code Security, treat every finding as carrying equal weight because they only have access to source files. But the source of truth for what actually matters in your system isn’t in the code. It’s in your design documents, your infrastructure configs, your runtime data, and your risk registers. Your deployment topology determines exposure. Your trust model determines exploitability. Your business rules determine whether a missing check is a critical flaw or an intentional exemption. None of that lives in a diff.
A vulnerability in an internal service sitting behind two layers of authentication is a categorically different risk from the same bug on a public-facing endpoint. Code scanners treat them the same. Gecko doesn’t.
Gecko ingests context from outside the application layer: design documents, infrastructure data, and runtime information, alongside code analysis. That context lets us align and rank findings against what genuinely matters in your system: your actual deployment architecture, your trust boundaries, your business logic. When we flag a finding, it’s because we can trace why it matters given how your application is actually deployed, not because the code pattern simply looks suspicious in isolation.
That context-alignment is the only way to scale security review accurately. AI-generated code has made the volume problem severe: more findings, lower signal, the same number of engineers to triage them. The answer isn’t more findings. It’s findings that map to real business risk, with the false positives filtered out by understanding your system, beyond your source files.
We verify findings with proof-of-concept exploits like CVE-2025-51459 RCE in plugin upload systems that chain multiple steps together, confirming real exploitability before anything reaches your team. That verification, combined with deployment context, keeps our false positive rate around 20 percent while surfacing the vulnerabilities that code-only scanners miss entirely.
Claude Code Review and Claude Code Security are strong demonstrations of how capable foundation models have become at reasoning over code. As enterprise security products, they’re both bounded by the same constraint: the source of truth about what actually matters in your system isn’t in the code.
Your business logic lives in design documents. Your deployment architecture lives in infrastructure configs. Your trust model lives in risk registers and architecture specs. Code-only scanners have no access to any of it, so they can’t tell a critical vulnerability from a theoretical one, and they can’t tell you which finding to fix first.
Gecko pulls in that external context to close the gap. We align findings to your actual deployment, your trust boundaries, and your business rules, so the vulnerabilities that reach your team are the ones that genuinely matter in your system, not the ones that simply look concerning in a source file. See how Gecko works or book a call with the team.
