Claude Code for security: reviews, vulnerability scans and safe setups

Claude Code helps with security work in three ways: it reviews code for vulnerabilities with /security-review and Anthropic's security plugins, it speeds up investigation work like tracing a bug or writing a threat model, and it can be locked down with permissions and an OS-level sandbox when you point it at code you don't trust. None of it replaces human review, but it finds and explains issues quickly.

This page is about using Claude Code as a security tool. For how Claude Code protects your machine, see Claude Code security. Below: the built-in review tools, how they compare, a workflow, example prompts, skills, and the setup to use when the code itself is a risk.

What can Claude Code do for security work?

• Review changes before merge. /security-review checks your branch's diff for injection, auth issues and data exposure.
• Scan a whole codebase. The Claude Security plugin maps the architecture, builds a threat model, hunts for vulnerabilities and verifies each finding.
• Catch issues as code is written. The security-guidance plugin reviews Claude's own edits during the session.
• Investigate. Trace user input from an endpoint to a sink, explain a CVE's impact on your code, or read a stack trace during an incident.
• Write the fix and the test. Turn a finding into a patch with a regression test that proves the hole is closed.
• Document. Draft threat models, runbooks and secure coding rules from your real code.

Anthropic's own security engineers work this way. Its post on how Anthropic teams use Claude Code says that "During incidents, the Security Engineering team feeds Claude Code stack traces and documentation to trace control flow through the codebase," and that the team "has Claude ingest multiple documentation sources to create markdown runbooks and troubleshooting guides."

Which security review tools does Claude Code have?

/security-review. The commands reference describes it as analyzing "the changes on your current branch for security vulnerabilities." To change what it looks for, the claude-code-security-review repo says you can copy its security-review.md into your project's .claude/commands/ folder and edit it, for example to add organization-specific false positive rules.

security-guidance. The plugin docs say it catches issues "such as injection, unsafe deserialization, and unsafe DOM APIs before the code reaches a pull request." It has three layers: a per-edit pattern check with no model call, an end-of-turn diff review and a deeper commit review. You can add your own rules in .claude/security-patterns.yaml and guidance in .claude/claude-security-guidance.md. The docs are clear that these are "guidance for the reviewer, not deterministic guardrails."

Claude Security. The Claude Security plugin runs "a multi-agent vulnerability scan of your codebase inside a Claude Code session." Each scan writes a CLAUDE-SECURITY-<timestamp>/ folder with a Markdown report, JSONL and a SARIF 2.1.0 file for GitHub code scanning. Patches go to a patches/ folder and are never applied automatically. The docs note that scans are nondeterministic, so two scans of the same code can surface different findings. It needs a paid plan, API access or a supported cloud provider, plus Python 3.9 or later.

What does a security review workflow look like?

1. Set the rules. Put your threat model notes, auth model and banned patterns in CLAUDE.md or .claude/claude-security-guidance.md.
2. Review every branch. Run /security-review before you open a pull request, then ask Claude to fix and test what it finds.
3. Scan regularly. Run the Claude Security plugin on one area at a time, such as the API layer or auth code, and keep the revision stamp with each report.
4. Gate pull requests. Add the GitHub Action or Code Review so every PR gets a pass, and keep your existing SAST and dependency scanners.
5. Verify findings. Ask for a proof: the input, the code path and a failing test. Treat unverified findings as leads, not facts.

Anthropic's help center puts it plainly: automated reviews "should complement, not replace, your existing security practices and manual code reviews."

Which prompts work well for security work?

These are example prompts written for this guide. They ask for evidence, not just a verdict.

Trace every place user input from the /api/search endpoint reaches a database query, shell command or HTML response. For each path, list the file and line, any sanitization on the way, and whether it is exploitable. Do not edit files.

Write a STRIDE threat model for the file upload feature: entry points, trust boundaries, assets, threats and existing mitigations. Cite the code for each mitigation and mark anything you could not confirm.

/security-review found a possible IDOR in the invoices controller. Write a failing test that shows one user reading another user's invoice, then fix it with an ownership check and confirm the test passes.

[CVE ID] affects the version of the XML parser in our lockfile. Find every place we parse XML, say whether external entities are enabled, and propose the smallest safe change.

Review the auth middleware for session fixation, missing CSRF checks on state-changing routes and tokens logged in plain text. Report findings with severity and a fix for each.

The security review prompts collection has 15 more.

Which security skills help?

Anthropic's official plugin marketplace also lists vendor security plugins, including Semgrep, Aikido and SonarQube.

How do you set up Claude Code safely for security work?

Security work often means reading code, issues or dependencies you don't trust, and any of them can carry text written to steer an agent. The prompt injection guide covers the attack in depth. The setup:

• Turn on the sandbox. The sandbox docs describe an OS-enforced boundary around shell commands. It is off by default; run /sandbox. By default sandboxed commands can still read most of the machine, "including credential files such as ~/.ssh and ~/.aws/credentials", so set filesystem.denyRead and the credentials options. Network access goes through a proxy whose allowed domains start empty.
• Know what it doesn't cover. File tools, MCP servers and hooks run outside the sandbox. For one boundary around everything, run Claude Code in a dev container or VM.
• Deny before you allow. Permission rules are evaluated "deny, then ask, then allow." Deny Read(./.env), secrets folders and network tools like Bash(curl *) for sessions that read untrusted input.
• Keep prompts on. Anthropic's permission modes table lists bypassPermissions for "Isolated containers and VMs only."
• Treat CI carefully. The security review Action's README says it "is not hardened against prompt injection attacks and should only be used to review trusted PRs." Require approval for workflows from outside contributors.

Anthropic's security docs list the habits for untrusted content: review suggested commands, avoid piping untrusted content directly to Claude, verify changes to critical files, use VMs to run scripts and make tool calls, and report suspicious behavior with /feedback. If you find a vulnerability in Claude Code itself, report it through Anthropic's HackerOne program, not in public.

How do you keep security checklists reusable?

Threat model templates, review checklists and secure coding rules are worth versioning. Kipt keeps prompts and Agent Skills as Markdown in a private GitHub repo you own, with {{name}} blanks for the service or endpoint under review, and installs your skills into Claude Code or Codex with one npx skills add command. To turn a checklist prompt into a skill, the free SKILL.md generator builds the SKILL.md in your browser.