A reviewer, not another pattern matcher
Claude Code Security Review tries to catch bugs that are hard to describe as a simple rule. It runs Claude Code against pull-request changes, asks for security analysis in context, filters findings, and can comment on affected lines. The advertised coverage includes injection, authorization, data exposure, weak cryptography, validation, race conditions, insecure configuration, supply-chain risks, dangerous deserialization, and cross-site scripting.
That breadth is attractive because serious vulnerabilities often depend on intent and data flow. A permission check may exist but protect the wrong object. A safe-looking helper may become dangerous only when called from a new route. Traditional static analysis remains valuable, but an agent reading a diff can raise questions outside a fixed rule set and explain a plausible attack path.
The action is diff-aware. For pull requests it examines changed files, which limits cost compared with repeatedly auditing an entire repository. Custom scan and false-positive instructions let a security team add its own boundaries. Claude Code users get a local counterpart through /security-review, and the supplied command file can be copied into a project for customization.
Installation is short, trust configuration is not
The quick start is a small GitHub Actions workflow. Check out the pull request, call the action, pass an Anthropic API key, and allow it to read repository contents and write pull-request comments. Inputs control artifacts, excluded directories, model, timeout, repeat scans, and custom instructions.
The example uses anthropics/claude-code-security-review@main. That is convenient for a trial but weak for a security workflow because the referenced code can change without review in the consuming repository. An open issue raises this supply-chain concern. A production workflow should reference a full commit SHA that the team has inspected, then update it deliberately. The absence of tagged GitHub releases makes that maintenance less friendly because there is no release line to follow.
The prompt-injection warning changes the audience
Anthropic states plainly that the action is not hardened against prompt injection and should review only trusted pull requests. It recommends approval for all external contributors before their workflows run. Source code, comments, fixtures, and documentation in a pull request can contain instructions intended to manipulate an agent. A security reviewer that follows hostile text may miss a flaw, disclose information available in its environment, or behave unexpectedly.
That makes automatic use on open contribution queues a poor fit. Maintainer approval reduces exposure but does not prove a change is safe. Keep job permissions minimal, avoid making unnecessary secrets available, and treat model output as untrusted advice. The action should not receive deployment credentials, broad repository write access, or authority to merge.
The tool filters out categories it considers noisy, including denial of service, rate limiting, resource exhaustion, generic validation concerns without proven impact, and open redirects. This may improve signal for some web applications, but it can conflict with a team's threat model. Multi-tenant services can care deeply about resource exhaustion. Review and customize those exclusions before judging the default output.
Two current reports undermine gatekeeping use
The most serious open report concerns cache restoration. With run-every-commit disabled by default, a SHA-less restore prefix can reportedly load a marker from an earlier commit in the same pull request. The action then skips the new commit and still appears green. The report includes a root-cause analysis and reproduction. An older issue also describes fixes being skipped and says every-commit scans increase quota use.
Until this is fixed and verified, green status does not prove the current commit was analyzed. Teams should inspect logs for the scanned SHA, consider every-commit runs despite the cost, and avoid making this check sufficient for merging. Scan freshness needs to be visible and machine-verifiable.
Another current report says the false-positive filter's API preflight hardcodes a retired Claude 3.5 Haiku model. According to the report, the request returns 404, filtering disables itself, and the successful result does not surface the degradation prominently. Findings are said to fail open rather than disappear, but the advertised noise-reduction stage is not operating as expected. This can waste attention and makes pipeline state ambiguous.
These are issue reports, not maintainer release notes, but both describe reproducible behavior against current code and remain open. For a security product, silent skips and silent feature degradation justify a conservative maturity score.
Project health and the right role
The repository drew substantial interest and its issue and pull-request queue remained active into August 2026. Contributors proposed hardening, dependency updates, provider support, prompt-injection tests, and fixes. The main repository push date, however, was February 2026, and there are no releases. Current community activity shows demand and investigation, but not a recently shipped upstream resolution to the headline problems. The combined open count includes issues and pull requests, not only confirmed defects.
The documentation is candid and useful. It explains permissions, inputs, architecture, finding classes, exclusions, local evaluation, custom instructions, and the prompt-injection boundary. That honesty helps buyers make the right decision.
Use Claude Code Security Review as an additional opinion on trusted changes. It may find contextual mistakes that deterministic tools overlook, and its explanations can accelerate human review. Do not swap out the rest of the security program. A strong stack combines reproducible static rules, dependency and secret scanning, tests, permission controls, and accountable human judgment, with this action adding one perspective rather than the final word.