How to Run a Claude Code Security Review Without Chasing False Positives

Run /security-review inside Claude Code before you commit a security-sensitive change. Treat every result as a hypothesis: require a concrete source-to-sink path, confirm the vulnerable behavior, then patch and test only verified findings. This produces a useful second review without turning an agent's confidence into proof.

The command is easy to confuse with Anthropic's newer Claude Security product. They are related security workflows, but they have different availability and operating models. This guide explains the distinction, gives you a reproducible local review process, and shows how to triage findings that do not survive inspection.

Choose the Right Claude Security Workflow

Use the local command when you want an on-demand review of work in your current Claude Code project. Use the GitHub Action when a trusted repository needs repeatable pull request checks. Claude Security is a separate Enterprise public beta with an organization-level GitHub integration and a web dashboard.

The /security-review command is not a replacement for dependency scanning, secret scanning, static analysis, tests, or a security review by someone who understands the system's trust boundaries. It is another reviewer that can trace code paths and explain possible impact.

Prerequisites

You need:

• a current Claude Code installation authenticated with a supported paid plan or API account;

• a repository that you or your organization is authorized to scan;

• a focused set of pending changes, preferably on a clean feature branch;

• the project's existing tests, linters, and security scanners available locally;

• enough context to explain the intended authorization, validation, and data-flow rules.

Update Claude Code and open your project:

claude update
cd path/to/your-project
claude

Inside the Claude Code session, run:

/security-review

The expected result is a list of potential vulnerabilities with locations, explanations, and remediation guidance, or a report that no qualifying findings were identified.

Step 1: Establish the Review Boundary

Before the scan, inspect what actually changed:

git status --short
git diff --stat
git diff

Remove generated files, unrelated formatting, and local secrets from the review boundary. A smaller, coherent diff gives both the agent and the human reviewer a clearer model of what the change is supposed to do.

Tell Claude the system's relevant invariants before starting. For example:

Review the pending changes for security issues.

Trust boundaries:
- Request fields are untrusted until the route schema validates them.
- Only organization admins may change billing settings.
- Database access must preserve tenant isolation.
- Redirect targets must remain on approved origins.

For every finding, identify the attacker-controlled source, the path to the
sensitive operation, the missing or bypassed control, and a concrete way to
verify the behavior. Do not propose a patch until the path is supported by code

This context does not tell the reviewer what conclusion to reach. It supplies the rules that the code is meant to enforce.

Step 2: Run /security-review

Start the command in the Claude Code session:

/security-review

Anthropic documents checks for issues such as injection, cross-site scripting, authentication and authorization flaws, insecure data handling, and vulnerable dependencies. The command can use code context that a pattern-only scanner may miss, but the result depends on the code it can inspect and the reasoning path it takes.

For a large repository, ask for a narrower follow-up review after the first result:

Limit the review to the pending diff and the authentication, authorization,
validation, and persistence code reached by that diff. Exclude generated files,
fixtures, vendored code, and build output. Preserve the same evidence standard
for every finding

Do not narrow away a shared authorization helper or data-access layer merely because it was not edited. Relevant context may sit outside the diff.

Step 3: Turn Every Finding Into an Evidence Record

Do not fix findings directly from the headline. For each one, capture:

1. Entry point: What can an attacker control?

2. Reachable path: Which functions carry that value to the sensitive operation?

3. Missing control: What validation, authorization, escaping, or isolation should stop it?

4. Impact: What data or operation becomes exposed, and under which preconditions?

5. Verification: What targeted test or safe local reproduction would fail before the fix?

Use a prompt like this:

For finding 2, show the exact source-to-sink path with file and line references.
Identify every validation or authorization check on that path. State the minimum
attacker capability and preconditions. Then propose one targeted test that
demonstrates the issue without changing production data

A plausible vulnerability name is not enough. If the claimed path cannot reach the sink, a required permission check already dominates it, or the input is constrained earlier by a trusted parser, record the finding as unsupported.

Step 4: Reproduce the Finding Safely

Prefer a focused unit or integration test over an ad hoc live-system experiment. The test should exercise the same entry point and prove the control failure.

For example, an authorization finding should become a test shaped like this:

Given a user from organization A
When the user requests organization B's protected resource
Then the endpoint returns a denial
And no protected fields are returned or changed

An injection finding should demonstrate that untrusted input reaches an interpreter or query boundary without the expected parameterization or encoding. Do not put exploit payloads into shared environments, scan code you do not own, or weaken safeguards to make a report reproducible.

If a safe reproduction is not practical, look for independent static evidence: a reachable call graph, a missing policy, a dangerous API contract, or an existing security test that fails under the claimed condition. Lower your confidence when the evidence is indirect.

Step 5: Patch Only Verified Findings

Once a finding is supported, ask Claude for the smallest change that restores the existing invariant:

Implement the minimal fix for the verified finding. Reuse the existing
authorization and validation helpers. Add the targeted regression test. Do not
change unrelated behavior or add broad catch blocks. Stop after showing the diff
and the exact tests to run

Review the patch as you would any security change:

• Does it enforce the control at the correct boundary?

• Does it reuse the system's source of truth instead of adding a second rule?

• Can another route or caller still reach the vulnerable operation?

• Does the regression test fail against the old behavior and pass after the fix?

• Could the patch create a denial of service, data leak, or compatibility regression?

Run the targeted test first, then the owning package's broader type, lint, and test checks. A green test that never exercises the vulnerable path is not confirmation.

Step 6: Run a Second Review on the Final Diff

After verified fixes pass, start a fresh review of the final pending changes:

/security-review

Ask the second pass to check both the original issue and the new code. This can catch a partial fix, a bypass in a sibling path, or a new problem introduced during remediation. Compare the two reports and note which findings were confirmed, rejected, or left unresolved.

Finish with the repository's standard review process. No automated security review should be the only approval gate for production code.

Common Failure Modes

/security-review is not available

Run claude update, restart Claude Code, and confirm that the session is authenticated with a supported paid plan or API account. The command runs inside the interactive Claude Code session, not as a shell executable.

The scan is slow or too broad

Review one coherent change at a time. Exclude generated, vendored, fixture, and build directories, but keep shared security controls in context. For a recurring CI workflow, the official GitHub Action supports excluded directories and custom scan instructions.

A finding sounds serious but has no reachable path

Request the exact source, sink, intervening controls, and preconditions. If the evidence cannot support reachability or impact, do not patch speculative behavior. Record why the finding was rejected so a later reviewer does not repeat the same investigation.

The same false positive returns

Add a concise project-specific rule only after you understand why the result is invalid. Anthropic's security-review repository documents copying the command into .claude/commands/ and adding organization-specific filtering instructions. Keep those instructions narrow so they do not suppress a real variant.

The GitHub Action would review untrusted pull requests

Do not expose the workflow's API key to untrusted code. Anthropic explicitly warns that the Action is not hardened against prompt injection and recommends requiring maintainer approval for external contributors before the workflow runs.

No findings were reported

Treat this as one review result, not proof that the code is secure. Run the normal scanners and tests, verify the highest-risk flows manually, and preserve independent human review.

Add Reviewed Integrations Without Mixing Credentials Into the Scan

Security review and external tool access are separate trust decisions. After the code change is reviewed, use Aident Loadout to let Claude Code discover current Actions, inspect their schemas, and keep credentials in Vault instead of placing provider secrets in prompts or repository files.

Give your agent this exact setup instruction:

Follow https://aident.ai/SETUP.md

Then start with a read-only request:

Search Aident Loadout for the code-hosting and issue-tracking integrations I use.
Show only read-only Actions first. Inspect each Action's schema, connection
status, operation type, and risk before executing anything

This does not make an Action safe by itself. It gives you a reviewable discovery and connection boundary before the agent acts. See how Aident connects Claude Code and Codex to real-world tools and how to reduce MCP context usage.

Use the Review as a Gate, Not a Verdict

The repeatable workflow is: define the trust boundaries, inspect the diff, run /security-review, demand evidence for every finding, reproduce safely, patch only verified issues, test the fix, and review the final diff again. It is slower than accepting every alert, but much faster than repairing speculative code changes or missing a real authorization path hidden behind a confident explanation.

Use Aident Loadout to connect reviewed code-hosting and issue-tracking Actions without putting provider credentials in the repository. For your first measurable run, review one security-sensitive diff and record how many findings were confirmed, rejected, and fixed before merge.

Sources

• Anthropic: Automated Security Reviews in Claude Code

• Anthropic: Use Claude Security

• Anthropic: Claude Code CLI reference

• Anthropic: Claude Code Security Review repository

• Anthropic: Security Review GitHub Action warning and configuration

Refresh this guide when Anthropic changes the availability, command behavior, GitHub Action hardening guidance, or Claude Security product contract.