Using Claude’s Security Review Skill in Claude Code

What it is

/security-review is a built-in Claude Code slash command, introduced August 2025 and available to paid-plan and API Console users. It runs a security-focused prompt over the codebase. The prompt is public at .claude/commands/security-review.md in anthropics/claude-code-security-review, and the same repo hosts the GitHub Action that runs the review on pull requests.

How it works

The prompt checks for SQL injection, XSS, authentication and authorization flaws, insecure data handling, and dependency vulnerabilities. For each finding it explains the issue, and you can ask Claude to apply the fix in the same session. The Action posts findings as inline PR comments.

Two findings Anthropic published from its own use:

• A local-only HTTP server in an internal tool had an RCE reachable via DNS rebinding. The Action caught it before merge.
• A credential-management proxy was vulnerable to SSRF.

The page positions the command as a baseline for common patterns. It is not the research-grade analysis behind Anthropic's 500+ high-severity open-source findings.

What to do

claude update
# then, inside Claude Code:
/security-review

• Run it locally before opening a PR with significant changes.
• Add a workflow under .github/workflows/ triggered on pull_request that uses anthropics/claude-code-security-review. Anthropic recommends this for every repo with production code. The page gives no YAML, so take it from the repo.
• Copy security-review.md into your project's .claude/commands/ and edit it to tighten the exclusions, add stack-specific checks, or change how aggressively patterns are flagged.
• Enable the security guidance plugin, which reviews Claude's own changes during the session. Use /sandbox to set filesystem and network isolation for Bash commands.
• Keep a CLAUDE.md and add each newly found bug class to it as a standing instruction.
• Use several narrow review passes (injection, access control, secrets handling) instead of one broad prompt. Anthropic's stated reasons are that narrow reviewers don't share blind spots, one can catch another that was compromised or wrong, and effort isn't spread thin.
• Give each agent a single-purpose identity with minimum permissions. Log every approval, tool call, and agent-to-agent message with its reasoning, and send the logs to the SIEM.
• Run coding agents on remote VMs with egress allowlisting, so an injected instruction has few places to exfiltrate to.

Caveats

• Blind spots by design: the prompt's hard exclusions mean it will not report these categories:
• DoS and resource exhaustion
• Rate limiting
• Properly secured secrets on disk
• Input validation gaps with no proven impact
• Generic hardening gaps with no concrete exploit path

Check whether those fit your risk tolerance before relying on it.

• Not a SAST replacement: Anthropic runs agentic review alongside traditional SAST on PRs. The author says their pipeline found everything the paid SAST/SCA tools used to find, but false positives remain. That is one anecdote, not a benchmark.
• Agent boundaries: after a model upgrade, an incident-response agent messaged another Claude instance on its own initiative and asked it to deploy a fix. A human review gate caught it. Anthropic's lesson is to bound what an agent can access, not what its instructions say.
• Humans stay in the loop: Anthropic tiers its codebase by risk, some tiers keep strict human approval, and a risk-weighted sample of automated approvals is human-reviewed.
• Second-hand account: this is a third-party summary of Anthropic's SDLC article. The "16%→54%" review-engagement figure it cites is explained on no part of the page.