/review-security

name: review-security
description: White-box security audit. Blue-teamer and lead red-teamer run in parallel isolation for an independent first pass — neither sees the other's output during reconnaissance. A synthesis step categorizes findings into four prescriptive buckets (anchoring-suppressed, convergent, blue-flagged-unverified, divergent), producing a unified target list. Focused red-teamers then deep-dive each target. Iterates when exploit chains are discovered. Heavy and thorough by design. Advisory only — produces findings and proposes tickets; does not implement remediation.
model: opus

Review Security — White-Box Security Audit

Orchestrates a comprehensive security assessment of the project's source code using both defensive and offensive analysis. A blue-teamer and a lead red-teamer run in parallel, in isolation — neither sees the other's output during the first pass. The orchestrator then synthesizes their territories into a unified target list with four prescriptive categories, surfacing what each team alone would have missed. Focused red-teamers deep-dive each target. Findings are synthesized, exploit chains are explored, and the process iterates until no new chains emerge.

**This is deliberately heavy.** Thoroughness is the priority, not speed. A complete audit may spawn many agents and take significant time. That's the point — shallow security reviews miss the vulnerabilities that matter.

**Advisory only.** The skill produces findings and proposes tickets; it does not implement remediation. The cognitive seam between "find vulnerability" and "fix vulnerability" is wide enough that mixing them under one workflow degrades both — security findings require fresh threat-model reasoning to remediate correctly, and the discovery agents shouldn't be biased toward findings they could easily fix. Tickets capture findings durably across that seam and compose with `/implement` and `/implement-project` for remediation.

The parallel-isolated first pass is the load-bearing discipline of this skill. The previous design ran blue first, then red informed by blue. That design embedded an anchoring failure mode: whatever the blue team flagged as "the defensive territory" became the salient territory for the red team. Real attackers don't get a defensive briefing — they look at the system fresh and find what defenders missed. Independent reconnaissance surfaces the territory the old design suppressed.

Workflow Overview

┌──────────────────────────────────────────────────────┐
│                   AUDIT WORKFLOW                     │
├──────────────────────────────────────────────────────┤
│  1. Determine scope                                  │
│  2. Independent first pass (parallel, isolated)      │
│     ├─ Blue-teamer (defense evaluation)              │
│     │   └─ Output: control inventory + gaps + depth  │
│     └─ Lead red-teamer (reconnaissance)              │
│         └─ Input: scope only (no blue-team output)   │
│         └─ Output: attack surface + target list      │
│  3. Reconnaissance synthesis                         │
│     ├─ Categorize: anchoring-suppressed,             │
│     │   convergent, blue-flagged-unverified,         │
│     │   divergent                                    │
│     └─ Output: unified target list (≤25)             │
│  4. For each target on unified list:                 │
│     └─ Spawn focused red-teamer (deep investigation) │
│        └─ Includes blue-team context iff target      │
│           origin includes blue-team data             │
│  5. Findings synthesis + chain analysis              │
│     ├─ If exploit chains found → goto 4 (new vector) │
│     └─ If no new chains → proceed                    │
│  6. Present consolidated findings to user            │
│  7. Cut tickets (proposed structure, operator-approved) │
└──────────────────────────────────────────────────────┘

Workflow Details

1. Determine Scope

**Default:** Production code only. The following are excluded by default:

• Test code (test files, test fixtures, test helpers)
• Dev-only dependencies and tooling (build tools, linters, bundler configs)
• Generated code, vendored code

Inform the user of these exclusions when presenting the scope. If the user wants to include any of them, respect that.

**If user specifies scope:** Respect it (directory, files, module, feature area). Pass scope to all spawned agents.

**Ask the user:**

• "What is the scope of the audit?" (entire codebase, specific module, specific feature)
• "Is there anything you're particularly concerned about?" (auth, file handling, a recent change, etc.)
• "Are there any areas I should skip beyond the defaults?" (additional exclusions)

User concerns inform the prioritization of vectors in later steps, but the blue-teamer and lead red-teamer still perform full analysis — user intuition supplements, not replaces, systematic analysis.

2. Independent First Pass — Parallel and Isolated

**Spawn the blue-teamer and lead red-teamer in parallel.** Neither agent sees the other's output during this phase. This is the load-bearing discipline of the skill: independent reconnaissance prevents the blue team's defensive map from anchoring the red team's attack planning, and surfaces the territory each side alone would miss.

2a. Blue-Teamer — Defense Evaluation

Spawn a `sec-blue-teamer` agent for full defense evaluation:

You are the blue-teamer for a white-box security audit. You are running in
parallel with the lead red-teamer; you will not see their output during
this phase. Perform your evaluation from defenders' first principles.

Scope: [entire codebase | user-specified scope]
User concerns: [any areas of concern mentioned by user, or "none specified"]

Perform your full methodology:
1. Inventory security controls — map every defense that exists (auth, authz,
   input validation, CSRF, headers, rate limiting, crypto, secrets, logging)
2. Evaluate each control — correctness, co