# Security review in Claude Code: step-by-step guide and GitHub Action automation in 2026 > How to check the security of a vibe project with /security-review in Claude Code. Setup steps, a GitHub Action template, 6 types of vulnerabilities, and honest limitations. Source: https://ailoot.ai/blog/en/claude-code-security-review/ Canonical: https://ailoot.ai/blog/en/claude-code-security-review/ Language: en Publisher: Ailoot (https://ailoot.ai/) Translation: guide-212 Revision: sha256-87bd50509d5481862165e97dffd3b9ce42df31838878db2ef6b305c591a4215f The author of the original material describes their experience: “I just ran security-review on my own vibe project, and the team found several real issues in 4 minutes that have already been fixed.” This is the same work that used to take an external consultant a day. Additional materials on configuring tools are in the [Ailoot documentation](https://ailoot.ai/docs/).
[Ailoot Guides](https://ailoot.ai/docs/)
## What is /security-review in Claude Code?
Highlights `/security-review` is a built-in Claude Code command that runs a security analysis of the entire project or current changes directly from the terminal. Anthropic launched it on February 20, 2026 as part of Claude Code Security and made it available to all Pro, Max, and API Console users. The request is paid for from your regular Claude API balance.
The command works in two modes. Local: run `/security-review` in the terminal, and Claude reads the repository and produces a report. Server-side: the same engine is installed as a GitHub Action and automatically comments inline on every Pull Request. Unlike classic SAST scanners (Snyk Code, Semgrep, SonarQube), `/security-review` does not work from fixed rules. It reads code like a live engineer: it traces data flow, understands what framework you use and where the trust boundaries are, and catches vulnerabilities that a rule does not describe.

Claude Code Security reads and reasons about your code as a human security researcher would: it understands how components interact, tracks how data moves through the application, and catches complex vulnerabilities that rule-based tools miss.

— Anthropic, https://www.anthropic.com/news/claude-code-security
This does not mean `/security-review` replaces an external pentest or live testing in a staging environment. It can automate part of the initial code review, but this article does not measure a fraction of audit coverage. Below, I’ll explain how to run it properly and what Claude will find in your project. ## How do you run /security-review in 5 steps?
Highlights Update Claude Code to the latest version, open the project in a terminal, run `/security-review`, wait for the report (1 to 5 minutes for an average project), read the severity verdicts, and ask Claude to apply fixes. The command works with any stack: Next.js, Django, FastAPI, Rails, Go, Rust. It requires no special configuration.
**Step 1. Update Claude Code.** The command works starting with the release dated February 20, 2026. ```bash claude update ``` If you installed Claude Code through npm, you can also do this: ```bash npm install -g @anthropic-ai/claude-code@latest ``` Check that `/security-review` has appeared: ```bash claude /help | grep security ``` **Step 2. Open the project and sign in to Claude Code.** ```bash cd ~/projects/my-vibe-project claude ``` **Step 3. Run the command.** Inside Claude Code, simply enter: ``` /security-review ``` Claude automatically goes through 3 analysis phases: 1. **Repository Context Research** - reads the structure and identifies the stack, routes, and database queries. 2. **Comparative Analysis** - compares the current state with typical vulnerability patterns for this stack. 3. **Vulnerability Assessment** - lists every suspicion with a confidence level on a scale of 1-10. Only findings with confidence ≥ 8 are included in the report. **Step 4. Read the report.** The output format is a markdown table. For each issue, Claude provides: - **File and line number** (for example, `src/auth/login.ts:42`) - **Severity** (HIGH / MEDIUM / LOW) - **Category** (`sql_injection`, `xss`, `auth_bypass`, `insecure_storage`) - **Description** - what is wrong - **Exploit Scenario** - how an attacker could use it - **Recommendation** - how to fix it **Step 5. Ask it to apply fixes.** After that, you can work with it like a regular agent: > “Apply the HIGH-severity fixes from the report, one at a time, with a PR description.” Claude will open each file and propose a change; you confirm it. On a real project, I closed 5 findings in 40 minutes instead of the planned 3 hours.
[Ailoot Guides](https://ailoot.ai/docs/)
## What vulnerabilities does /security-review find?
Highlights Claude catches 6 classes: SQL injection and injections in general, XSS, authentication and authorization issues, sensitive data leaks, holes in third-party dependencies, and hardcoded secrets in code. The command can also work with auth logic spread across multiple files, which rule-based scanners cannot do.
The full list of what is included in the analysis by default is described in the [official Anthropic documentation](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code): | Category | What it looks for | |----|----| | **SQL injection** | Direct string concatenation in SQL, unsafe ORM calls (`raw()` without parameters), Prisma `$queryRawUnsafe` | | **XSS** | Rendering with `dangerouslySetInnerHTML` without sanitization, template systems without auto-escaping, `innerHTML` from user input | | **Auth flaws** | Reusable tokens, missing permission checks in API routes, JWT without an expiration date, session fixation | | **Insecure data handling** | Client-only validation, responses with extra fields (over-fetching), open redirect | | **Dependency vulnerabilities** | Vulnerable versions of npm/pip/cargo packages, checked via `npm audit` and equivalents | | **Secrets** | Hardcoded API keys, tokens in `.env.example`, passwords in code | Additionally, the command covers categories that automated scanners rarely cover: - **Command injection** - executing user input in a shell (`child_process.exec(userInput)`) - **Path traversal** - loading a file via `../../etc/passwd` - **XXE** - XML with external entities - **Template injection** - SSTI in Jinja/Handlebars/EJS - **NoSQL injection** - `$ne`, `$gt` operators in MongoDB queries - **Crypto misuse** - using MD5, ECB mode, a static IV Claude gives each finding a severity. The scale is simple: - **HIGH** - remote exploitation without authentication, data leak affecting all users - **MEDIUM** - exploitation with additional conditions (a session is required / specific input) - **LOW** - a potential vector, not critical now, but worth fixing Useful to know: in the standard configuration, Claude **does not report** DoS, rate limiting, memory exhaustion, open redirects without proven impact, regex injection / ReDoS, or log spoofing. This is intentional, so you are not flooded with noise. If these classes matter, extend the rules (see the section on false-positive filtering below). ## How do you set up a GitHub Action for automatic review?
Highlights Anthropic released the official action `anthropics/claude-code-security-review@main`. It connects with a single workflow file and automatically comments inline on every Pull Request with vulnerabilities it finds. Configure `CLAUDE_API_KEY` and the workflow permissions. The official Action warns that it is not hardened against prompt injection and should review trusted PRs; review contributor and workflow access before enabling it.
**Step 1. Get an API key.** Go to [console.anthropic.com](https://console.anthropic.com/), create an API key, and copy it. **Step 2. Put the key in the repository secrets.** In GitHub: Settings → Secrets and variables → Actions → New repository secret. Name it `CLAUDE_API_KEY`; the value is your key. **Step 3. Create a workflow file.** Save it as `.github/workflows/security.yml`: ```yaml name: Security Review permissions: pull-requests: write contents: read on: pull_request: jobs: security: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha || github.sha }} fetch-depth: 2 - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} ``` **Step 4. Merge the branch into main.** The action will start automatically with the next PR. **What the action does:** - Runs on every open / synchronize Pull Request. - Takes the diff between the PR branch and main. - Runs the same engine as local `/security-review`. - Posts inline comments directly on code lines with a suspicion. - Duplicates the full report in the Job Summary. **Important details in `permissions`:** - `pull-requests: write` - to post inline comments. - `contents: read` - to read code. No `write`. The action does not modify code itself; it only reports. This set is sufficient for a private repository. For a public repo, you can additionally specify `actions: read` if you use reusable workflows. ## How do you filter false positives and change sensitivity?
Highlights The action has 9 inputs you can use to configure its behavior for your project. The main ones: `exclude-directories` (for example, `tests/,fixtures/`), `false-positive-filtering-instructions` (path to an md file with your rules about “this is not a vulnerability because...”), and `custom-security-scan-instructions` for additional domain-specific checks.
Full table of GitHub Action inputs ([source: repository README](https://github.com/anthropics/claude-code-security-review)): | Input | Default | What it does | |----|----|----| | `claude-api-key` | \- | Anthropic API key. Required. | | `comment-pr` | `true` | Whether to post inline comments in the PR | | `upload-results` | `true` | Whether to save the result as an artifact for 90 days | | `exclude-directories` | \- | Comma-separated: `tests/,docs/,fixtures/` | | `claude-model` | `claude-opus-4-1-20250805` | Which model to use | | `claudecode-timeout` | `20` | Timeout in minutes | | `run-every-commit` | `false` | Run on every push, not only on PRs | | `false-positive-filtering-instructions` | \- | Path to an md file with your rules | | `custom-security-scan-instructions` | \- | Path to an md file with additional checks | **Example of configuring false-positive filtering.** Create the file `.claude/security/false-positives.md`: ```markdown # False positive filtering rules for our project - Any `dangerouslySetInnerHTML` inside `src/lib/email/layout.ts` is safe - the HTML is assembled from trusted templates and passes through `sanitize-html` at database write time, not at render time. - Do not report hardcoded test API keys in `__tests__/fixtures/*.ts`. All keys start with `sk-test-fake-`. - SQL concatenation in `src/lib/admin/migrations.ts` is acceptable - the file runs only as root, and input data comes from environment variables. ``` Connect it in the workflow: ```yaml - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} false-positive-filtering-instructions: .claude/security/false-positives.md ``` **Custom security scan instructions** are similar. Create a file with rules that are critical specifically for your project: ```markdown # Additional checks for our project - Any endpoint under `/api/admin/*` must check the administrator role through a shared wrapper. Without this wrapper, it is HIGH severity. - All YooKassa / CloudPayments webhooks must verify the signature before parsing the body. Without this, it is HIGH severity. - Magic-link tokens must be single-use (marked as used after the first valid request). Reusable tokens are MEDIUM severity. ``` This is no longer an Anthropic preset: you are transferring your expertise about the project into rules that Claude applies every time. That is the essence of “methodology over model.” For more on context methodology for Claude, see the guides [“How to configure CLAUDE.md”](https://ailoot.ai/blog/en/claude-md-template/) and [“The Second Brain in Claude Code”](https://ailoot.ai/blog/en/claude-code-second-brain/). ## What does Claude NOT catch and why: honest limitations?
Highlights A code review does not by itself exercise the running application or verify its deployed environment. It may flag potential race conditions, business-logic flaws, or configuration issues present in the code, but staging tests and inspection of the actual deployment are needed to confirm behavior and remaining risks.
Anthropic clearly lists what is disabled by default and why ([source: repository README](https://github.com/anthropics/claude-code-security-review)): - **Denial of Service** - too much noise, almost always low impact. - **Rate limiting concerns** - handled at the infrastructure level, not in code. - **Memory / CPU exhaustion** - same. - **Generic input validation without proven impact** - validating every field creates a false-positive volcano. - **Open redirect** - often intended behavior. What code review alone cannot fully verify without runtime or deployment evidence: - **Production server configuration.** NGINX headers, CORS policies, TLS settings, listening ports. These need to be checked manually in a staging environment. - **Race conditions.** For example, double-spending during simultaneous refund requests. Static analysis can flag suspicious patterns, but concurrent behavior still needs testing. - **Payment business-logic flaws.** If your order total is calculated on the client and simply sent to the payment provider, that is HIGH severity, but Claude does not always see this pattern without explicit context about how payment is supposed to work. - **Database-level IDOR.** If the query `SELECT * FROM orders WHERE id = $1` does not check `WHERE user_id = $session.userId`, Claude often catches it. But if the check is implemented through ORM middleware and Claude cannot see the full data flow, it may miss it. - **Social engineering / phishing resistance.** It has nothing to do with code. Use `/security-review` as an initial static review. Follow it with dynamic tests in staging, role and permission checks, relevant SAST checks, and review of the actual deployed configuration. No measured coverage percentage is established here. Decide the scope and timing of an external assessment from your system’s risks and changes. Neither one command nor a periodic external audit establishes 100% security coverage. ## How the author of the original material ran a security review on a vibe project
Highlights I ran `/security-review` on my own TypeScript project with Next.js, Prisma, PostgreSQL, and Redis. In 4 minutes, the command performed an initial audit, returned several well-supported findings of varying severity, and I ultimately completed the working fixes in an hour and a half. This was cheaper and faster than any external pentest.
What came up. A typical picture for an average vibe project at the “works in production, but has not been reviewed” stage: several suspicions about the auth flow, the logic for processing webhooks from the payment integration, file upload handling, and a couple of specific notes on HTML handling at render time. I am not describing the details publicly; some recommendations have already been applied, and others are still in PR. In this reported project, the initial scan was useful and fast; it does not establish an audit-coverage percentage or a general completion time. What I discarded as false positives: - Findings about DoS through regexes in input validation - the real load does not fall on those regexes. - One finding about a hardcoded API key - it was a test key with an explicit `fake-` prefix in fixtures. How long it took. The run itself took 4 minutes. Reviewing the report took 25 minutes. Applying fixes took about an hour with tests. Total: about an hour and a half from “started” to “everything in main.” An external pentest on the same surface takes a calendar week and costs dozens of times more. Main takeaway. `/security-review` does not replace an external pentest. It can identify useful code-level findings, as it did in the author’s reported four-minute scan. Review and test the fixes, then check runtime behavior and deployed configuration separately; the scan does not eliminate the project’s security risk. ## How do you integrate /security-review into your pre-commit routine?
Highlights Before committing significant changes, run `/security-review` in the project session, read the findings, fix the confirmed issues, and rerun the relevant tests. This is a review procedure, not a technical prohibition on committing.
The previously shown hook using `git_commit`, `--severity HIGH`, and `--fail-on-find` is not a documented working recipe and must not be used as a security gate. This article supplies no verified local commit-blocking hook. The official GitHub Action shown above provides automated PR findings; do not infer that it blocks commits or merges merely because it comments on a PR. A full explanation of hooks is in the [“Hooks in Claude Code”](https://ailoot.ai/blog/en/claude-code-hooks/) guide. An alternative using [routines](https://ailoot.ai/blog/en/claude-code-routines/) is to create a `pre-deploy-check` routine that runs `/security-review` + `npm run build` + `npm run test` with one command. Additional materials are in the Ailoot documentation. If you use [MCP servers](https://ailoot.ai/blog/en/mcp-servers-claude-code/), you can integrate findings from `/security-review` with an incident system (Sentry, Linear, Notion) so each HIGH automatically becomes a ticket. ## FAQ about /security-review
Highlights 5 common questions: how much it costs, how often to run it, which stacks it works with, what to do if Claude has already found this vulnerability, and whether you can run it only on specific files. Short answers, no fluff.
**How much does one run cost?** It depends on the project size. On my 30K lines, one run uses about \$0.30-0.50 of API balance. A large enterprise repository with a million lines costs up to \$5-8 per run. That is dozens of times cheaper than any SaaS scanner subscription. **How often should I run it locally?** At a minimum, before every production release. Also consider it before significant commits and PRs. This article does not provide a verified automatic commit-blocking hook. **Which stacks does it work with?** Any that Claude can read. According to the author's observations, these have been checked: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Quality is lower on very exotic languages (Erlang, Elixir, Clojure), but it will find something. **What should I do if Claude finds the same “vulnerability” every time, even though it is not actually a vulnerability?** Add it to `false-positive-filtering-instructions` with an explanation of “why this is safe.” Claude will stop reporting it in future runs. **Can I run it only on specific files?** Locally, yes: simply run `/security-review src/lib/auth/*.ts`. In the GitHub Action, only the current PR diff is checked, which is usually what “specific files” means. ## Sources
### Sources - [Anthropic - Claude Code Security launch announcement](https://www.anthropic.com/news/claude-code-security) - official announcement dated February 20, 2026 - [Anthropic Help Center - Automated Security Reviews in Claude Code](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) - official instructions for running it - [GitHub: anthropics/claude-code-security-review](https://github.com/anthropics/claude-code-security-review) - GitHub Action source with full README - [Claude Code Docs - Code Review](https://code.claude.com/docs/en/code-review) - general Anthropic documentation - [Anthropic Help Center - Use Claude Security](https://support.claude.com/en/articles/14661296-use-claude-security) - related products - [Port - Ingest Claude Code Security Reviews](https://docs.port.io/guides/all/ingest-claude-code-security-reviews/) - integrating results into an Internal Developer Portal - [Claude Code Changelog](https://code.claude.com/docs/en/changelog) - command release history
Additional materials are in the [Ailoot documentation](https://ailoot.ai/docs/).
[Ailoot Guides](https://ailoot.ai/docs/)
[Go to Ailoot](https://ailoot.ai/)
## Questions about Security review in Claude Code: step-by-step guide and GitHub Action automation in 2026 ### Does a clean security-review report prove the application is secure? No. It is an initial code review with possible false negatives and filtering. Verify fixes, exercise role and concurrency behavior in staging, and inspect the actual deployed configuration. ### Does the GitHub Action shown here automatically block commits or merges? No such guarantee is established by the shown workflow. It posts PR findings. Review them and test confirmed fixes; the article supplies no verified local commit-blocking hook. ## Ailoot · The company and its project portfolio Ailoot combines established operating experience, a large client base, stable service and ongoing KPI control. The company and its project portfolio: millions of customers; monthly sales in the billions. Ailoot brings that operating experience to API access for AI features in customer products, agents, applications and automations.