Claude Code Security Plugin Scans for 25 Vulnerability Classes

Anthropic shipped the security-guidance plugin for Claude Code on May 27, and it is free for every plan. The plugin monitors every file edit, turn, and git commit Claude makes, automatically flagging roughly 25 vulnerability classes and using a separate Claude Opus 4.7 instance to review the code before it reaches a pull request.

Anthropic's internal rollout showed a 30-40% reduction in security-related PR comments on projects using the plugin. That is the number to hold onto: not a conceptual improvement, but a measurable drop in the review work that falls to human reviewers downstream.

Why AI-Generated Code Has a Security Blind Spot

The security problem with AI-assisted development is not that AI writes insecure code more often than humans. It is that AI writes code faster, so the rate at which insecure patterns enter a codebase accelerates. A vibecoder shipping a full feature in a two-hour session might produce as many changed lines as a week of conventional development. Security tooling built around human-speed code production does not scale to that output rate.

The standard practice, static analysis in CI and security review at PR time, arrives too late in that workflow. By the time a PR is open, the developer has mentally moved on, the code is integrated with other changes, and rework costs are higher. The plugin shifts the detection point from "after the code is written" to "while Claude is writing it."

There is a second problem the plugin addresses: self-review bias. When the same Claude instance that wrote the code evaluates it for vulnerabilities, the evaluation is influenced by the reasoning that produced the original approach. The reviewer has context on why the code was structured that way, which makes it more likely to rationalize edge cases rather than flag them.

Installation is one command in any Claude Code session, then a reload:

/plugin install security-guidance@claude-plugins-official
/reload-plugins

After that, the plugin runs automatically on every session. There is nothing to invoke manually and no separate command to remember.

How the Three Review Levels Work

The plugin reviews Claude's code at three escalating levels of depth, trading off latency for thoroughness.

Level 1: Per-edit pattern check. Every time Claude writes to a file, the plugin runs a deterministic string match with no model call, adding zero usage cost. The built-in pattern categories include dynamic code execution (eval(), new Function(), os.system(), child_process.exec()), unsafe deserialization (pickle), DOM injection vectors (dangerouslySetInnerHTML, .innerHTML =, document.write), and any edits to .github/workflows/ files that can grant repository-level permissions. Each warning fires once per pattern per file per session, so the conversation does not flood with repeated noise on the same file.

Level 2: End-of-turn diff review. After Claude finishes each response, the plugin computes a git diff of everything that changed during that turn, including changes from Bash commands and subagents, and sends it to a separate Opus 4.7 review. The review runs in the background, so Claude's reply is not delayed. If the reviewer finds issues, Claude is re-prompted and addresses them as a follow-up step in the same session. This layer catches logic-level problems that string matching cannot find: authorization bypass, insecure direct object references, server-side request forgery, injection, and weak cryptography. It covers up to 30 changed files per turn and re-prompts at most three times before yielding control back to you.

Level 3: Commit and push review. When Claude runs git commit or git push through its Bash tool, the plugin runs a deeper agentic review. Unlike the end-of-turn review, this one reads surrounding code: callers of changed functions, existing sanitizers, and related files in the repository. That extra context keeps false positives low on patterns that look dangerous in isolation but are safe in your specific codebase. The review is capped at 20 per rolling hour and does not re-prompt if findings duplicate what the end-of-turn review already caught.

One constraint worth stating clearly: none of the three layers block writes or commits. Findings reach the writing Claude as instructions; Claude decides whether and how to address them. The official documentation is direct on this: "treat the plugin as one layer of defense in depth, not a complete security solution."

What the Independent Reviewer Architecture Changes

The most meaningful design choice in the security-guidance plugin is using a separate Claude instance to review code rather than asking the same session to critique its own output.

When Claude generates a solution and then evaluates it in the same context, the evaluation is biased toward confirming the approach. The same reasoning that led to the original implementation influences what the reviewer notices and what it rationalizes away. This mirrors the human phenomenon of code review by the original author: consistently less effective than review by someone who had no hand in writing the code.

The plugin's end-of-turn and commit reviewers start from a diff with no conversation history. They receive only the changed code and a security-focused prompt. They do not know why the code was structured a certain way, what constraints the developer was working within, or what alternatives were considered. That absence of context is a feature. A reviewer without investment in the approach is more likely to surface what a fresh human reviewer would surface.

The customization layer is worth knowing about. Adding .claude/claude-security-guidance.md to a project provides additional context to both model-backed reviewers: team-specific threat models, logging policies, access control patterns required on specific routes. A .claude/security-patterns.yaml file extends the per-edit pattern check with custom regex or substring rules. Both files are additive only; they cannot suppress built-in patterns. Check either file into the repository and the rules apply to every developer who clones it.

The usage cost model matters for planning. The per-edit check costs nothing because no model is involved. The end-of-turn and commit reviews each use Opus 4.7 calls counted toward your plan like any other request. In practice, expect roughly one review call per turn that changes files and one agentic review per commit Claude makes. Both model-backed reviews default to Opus 4.7 but can be switched to a faster or cheaper model via the SECURITY_REVIEW_MODEL and SG_AGENTIC_MODEL environment variables if you want to reduce overhead in sessions where the code is low-risk.

What This Means For You

The plugin installs once and runs automatically. It does not require any change to how you work with Claude Code day-to-day.

• If you are building anything that handles user input or authentication: Install it now. SQL injection, command injection, XSS, authorization bypass, and SSRF are the vulnerability classes most likely to appear in AI-generated code that touches user data, and the plugin's end-of-turn reviewer specifically targets all of them.
• If you run a team on Claude Code: Add the plugin to .claude/settings.json and commit it to the repository. That enables it for every local and cloud session without each developer needing to install it individually.
• If you are shipping a solo product: The 30-40% reduction in security-related PR comments means less review overhead per ship. The plugin handles the obvious patterns in session so your review round can focus on business logic.
• If you are on a regulated team: The commit-level agentic review, which reads callers and sanitizers before deciding whether a finding is real, reduces the false-positive noise that makes automated security tooling frustrating to use in complex codebases.
• If you want to extend coverage: The .claude/claude-security-guidance.md file is the practical tool for encoding what your team's specific threat model looks like. A few lines about your multi-tenant data model or your logging policy can turn the plugin's generic reviewer into one that understands your codebase's particular risks.