security-review

/security-review

When to use

• Before committing changes that touch authentication, authorization, cryptography, user-input handling, file/path operations, request handling (routes/middleware/templates), or anything that reads/writes secrets.
• When the security-nudge Stop hook prints a one-liner suggestion.
• Whenever you want a second pair of eyes on a diff before pushing — Sonnet running on isolated context will catch things Opus inline missed about a third of the time in informal testing.

What it does NOT replace

• Static analysis (Semgrep, CodeQL, Bandit) — those have rule sets built by full-time security teams. Run them separately in CI.
• Dependency vulnerability scanning (npm audit, pip-audit, cargo audit, GitHub Dependabot). The skill flags suspicious package additions but does not check CVE feeds.
• A real pentest. This is a diff review by a model, not an attacker exercising your live system.

How it runs

sequenceDiagram
    participant U as User
    participant M as Main session (Opus)
    participant S as security-reviewer (Sonnet)

    U->>M: /security-review
    M->>M: git diff --cached
    M->>S: Task: review this diff for OWASP Top 10 patterns
    S->>S: Read diff + surrounding context
    S->>S: Pattern-walk + tier findings
    S-->>M: Markdown report (Critical / Important / Nice / OOS)
    M->>U: Relay report verbatim + offer "fix all Critical, fix one, ignore"

1. Main session reads the staged diff (git diff --cached; falls back to git diff if nothing staged).
2. If diff is empty, report "no changes to review" and stop.
3. Delegate to security-reviewer subagent (Sonnet, read-only). Pass:
   • The full diff
   • The list of changed files
   • The current branch and git log --oneline -5 for context
4. Receive the structured Markdown report.
5. Relay the report verbatim to the user. Do not paraphrase, summarize, or pre-emptively fix anything.
6. Ask the user: "Fix all Critical findings, address one specific finding, or commit as-is and address later?"