A Claude Code skill that runs a full, multi-phase security review of a code repository — secret scanning, architecture and threat analysis, dependency CVEs, OWASP code review, and independent validation — then writes a single markdown report. Each phase runs as an isolated subagent, and findings pass through a finder → judgment trust boundary before they reach the report.
Works on a single repo or across multiple microservices, has a dedicated mode for auditing third-party/open-source tools before adopting them, and a fast diff-scoped mode for reviewing a single pull request without scanning the whole repo first.
Full specification: SKILL.md.
Skills live under ~/.claude/skills/. Clone the repo there so updates are a git pull away:
mkdir -p ~/.claude/skills
git clone https://github.com/<your-org>/repo-security-review ~/.claude/skills/repo-security-reviewInstall the external scanners the phases use (gitleaks, osv-scanner, semgrep, jq, and optionally docker for --runtime):
bash ~/.claude/skills/repo-security-review/scripts/setup.shThe script installs whatever it can via brew, go, or pip3. Any missing tool just degrades the matching phase — the pipeline never aborts. To update later: cd ~/.claude/skills/repo-security-review && git pull.
In any Claude Code session (CLI or Desktop), point the skill at a local repo path:
/repo-security-review /path/to/repo
# Skip phases you don't need, copy the report somewhere
/repo-security-review /path/to/repo --skip secrets,dependencies --output ~/reports/myapp
# Generate PoCs for confirmed findings
/repo-security-review /path/to/repo --poc
# Runtime PoC validation in Docker (implies --poc)
/repo-security-review /path/to/repo --runtime
# CI / headless — validation only (default: no PoC files), no prompts
/repo-security-review . --output ./security-report --yes
# Calibrate severity for a local-only tool behind auth
/repo-security-review /path/to/repo --context deployment_target=local,auth_required_to_reach=true
# Multi-repo — analyze several services, get a system-level report
/repo-security-review --repos ~/svcs/auth,~/svcs/gateway,~/svcs/users --output ~/reports/my-system
# Vendor audit — is this third-party/open-source tool safe to adopt internally?
/repo-security-review /path/to/vendor-tool --vendor --output ~/reports/vendor-tool
# PR review — diff-scoped, no full-repo scan required first
/repo-security-review /path/to/repo --pr main...feature/add-export
| Flag | Default | Effect |
|---|---|---|
--repos <paths> |
none | Comma-separated repo paths → multi-repo mode (adds cross-service topology + synthesis). |
--skip <phases> |
none | Comma-separated: secrets, architecture, dependencies, owasp, skill-security, validation. |
--output <dir> |
none | Copy the report and PoC scripts into this directory after the run (created if needed). |
--poc |
off | Opt-in: generate a PoC for each finding Phase 5 confirms. Without it, Phase 5 still validates every finding, but writes no PoC files. |
--runtime |
off | Stand the app up in Docker and run each confirmed PoC against it. Implies --poc. |
--vendor |
off | Third-party adoption audit. Skips secrets/dependencies, forces PoC generation off, pins all phases to Sonnet, and produces an adoption-risk report (verdict + conditions + "what it does" + adopter-side controls). |
--pr <base>...<head> |
none | PR review mode. Reviews only a pull request's diff — no full-repo scan needed first. --pr <base> is shorthand for <base>...HEAD. Pins to Sonnet, writes pr-report.md. Mutually exclusive with --repos and --vendor. |
--context <pairs> |
none | Inline threat model to calibrate severity: deployment_target=local|public, auth_required_to_reach=true|false. Softens only — never sharpens. |
--yes |
off | Non-interactive / CI mode — auto-confirms prompts (safety path checks still apply). |
--debug |
off | Write .security-review/execution-log.md showing how Phases 2, 4, 5, and 6 actually ran, plus per-phase token consumption. |
--sonnet |
off | Experimental A/B flag: runs Phase 2 (architecture) on the Sonnet family instead of Opus, to compare scan quality and token consumption. No effect in --vendor or --pr mode (both already pin to Sonnet with no Deep tier). |
--skill-security |
off | Opt-in: run Phase 4b (LLM/AI skill security) on a mixed repo that also contains a SKILL.md/.claude/commands/. Without it, a mixed repo never runs Phase 4b by default — just having those files present isn't reason enough, since ordinary CLAUDE.md/AGENTS.md docs are common in AI-assisted projects. Redundant on a repo that's entirely skill/agent content (Phase 4b auto-runs there regardless) and in --vendor mode (already auto-runs it). |
--help |
— | Show usage. |
Skip cascades (applied silently): --skip owasp also skips validation (and PoC generation has nothing left to run against); --skip validation means --poc has no effect; --skip architecture also skips skill-security. --vendor forces skip of secrets and dependencies, and forces PoC generation off regardless of --poc. In --pr mode the same skip names apply but target its own steps instead of numbered phases, and architecture cannot be skipped (its diff-scoped context is load-bearing for every other step); --poc has no effect in --pr mode.
Working artifacts go to <repo>/.security-review/ (per-phase JSON, pocs/, and final-report.md); --output copies the report + PoCs out. In multi-repo mode, start from system-report.md in the output directory. In --pr mode, artifacts use pr--prefixed filenames (pr-findings.json, pr-validated.json, pr-report.md) so they never collide with a prior or later full scan's output in the same repo.
flowchart TD
Start([/repo-security-review <repo>/]) --> P1
subgraph FINDER["FINDER LAYER (sequential subagents)"]
P1[Phase 1 · Secret Scanning<br/>gitleaks + grep]
P2[Phase 2 · Architectural Analysis<br/>deep-tier model · extended thinking]
TS[(tech-stack.json)]
P3[Phase 3 · Dependency CVEs<br/>osv-scanner]
P3b[Phase 3b · Reachability Validation]
P4[Phase 4 · OWASP Code Scan<br/>semgrep + LLM]
P4b[Phase 4b · LLM / AI Skill Security<br/>standard-tier model<br/>auto-activated for pure skill repos<br/>opt-in via --skill-security for mixed repos]
P1 --> P2
P2 --> TS
TS --> P3
P3 --> P3b
P3b --> P4
TS -. also read by .-> P4
TS -. skill_files .-> P4b
P4 --> P4b
end
P4b -. file path only .-> P5
P2 -. file path only .-> P5
subgraph JUDGMENT["JUDGMENT LAYER (isolated context)"]
P5[Phase 5 · Validate + PoC<br/>merges + validates Phase 4 findings<br/>and standalone Phase 2 findings<br/>verdict: Confirmed / Needs Review / Rejected<br/>PoCs only for Confirmed<br/>optional Docker runtime]
end
P1 --> R[Phase 6 · Report Builder]
P2 --> R
P3b --> R
P4b --> R
P5 --> R
R --> Out([final-report.md: Findings + Needs Review + False Positives, plus pocs/])
classDef finder fill:#eef6ff,stroke:#5b8def,color:#1a1a1a
classDef judgment fill:#fff4e6,stroke:#e0883a,color:#1a1a1a
classDef report fill:#e8f5e9,stroke:#5a9a5a,color:#1a1a1a
classDef store fill:#f5f5f5,stroke:#888,color:#1a1a1a,stroke-dasharray: 3 3
class P1,P2,P3,P3b,P4,P4b finder
class P5 judgment
class R report
class TS store
PR review mode (--pr) is a separate, single-agent mode — not a variant of
the pipeline above. It never runs Phases 1–4 or 7; it runs
references/pr-review.md directly (Steps 0–5 gather diff-scoped context and
scan, Step 6 validates in isolation, Step 7 writes pr-report.md), bounding
file reads to the diff plus whatever a repo-wide grep specifically points to.