Security Review

Identify HIGH-CONFIDENCE security vulnerabilities with real exploitation potential. Two-axis scoring (severity + confidence), OWASP 2025 aligned, false positive filtered.

Parse Arguments

Output Path Configuration:

• If $ARGUMENTS contains --post-to-pr: enable GitHub PR posting (Phase 6)
• Remaining non-flag arguments: use as output directory (default: ./reviews/security/)

Example usage:

• /review:security-review — local report to ./reviews/security/
• /review:security-review audits/sec — local report to audits/sec/
• /review:security-review --post-to-pr — local report + post to GitHub PR
• /review:security-review audits/sec --post-to-pr — both

Git Analysis

GIT STATUS:

!`git status`

FILES MODIFIED:

!`git diff --name-only origin/HEAD...`

COMMITS:

!`git log --no-decorate origin/HEAD...`

DIFF CONTENT:

!`git diff --merge-base origin/HEAD`

Review the complete diff above. Focus ONLY on security implications newly added by this PR.

Objective

• Only flag issues where you have HIGH confidence of actual exploitability
• Skip theoretical issues, style concerns, or low-impact findings
• Prioritize vulnerabilities leading to unauthorized access, data breaches, or system compromise
• Use two-axis scoring: severity (impact) and confidence (accuracy) are independent

Security Categories (OWASP 2025 Aligned)

See WORKFLOW.md for detailed subcategories and severity assignment reference.

Analysis Methodology

Phase 1 — Repository Context: Identify existing security frameworks, sanitization patterns, and security model in the codebase.

Phase 1.5 — Automated Security Scan (Optional): Run Trivy (vulnerability/IaC scanning) and Gitleaks (secret detection) if available. Locate the scan script via Glob for **/review/scripts/security-scan.sh, then execute: bash {script_path} --quick --output-dir {output-directory}. If tools are not installed, skip gracefully — this phase is informational only. See WORKFLOW.md for details.

Phase 2 — Comparative Analysis: Compare new code against established secure practices. Flag deviations and new attack surfaces. Cross-reference with automated scan results if available.

Phase 3 — Vulnerability Assessment: Trace data flow from user inputs to sensitive operations. Confirm sink reachability and check for sanitizers in the path.

See WORKFLOW.md for detailed methodology and sub-task orchestration.

Two-Axis Scoring

Severity (Impact)

Confidence (Accuracy)

Confidence & Signal Quality

Before reporting any finding, assess using both axes:

Finding caps: Max 8 meaningful findings (Blocker + Improvement + Question) and max 2 Nits per review. Keep the highest-severity, highest-confidence items.

Self-reflection: After generating all candidate findings, re-evaluate each in context. Remove redundant, low-signal, or theoretical items. Apply false positive filtering from WORKFLOW.md.

Triage Matrix

Categorize every finding:

• [Blocker]: Must fix before merge — CRITICAL/HIGH severity + HIGH confidence. RCE, auth bypass, injection with confirmed data flow (confidence >= HIGH)
• [Improvement]: Strong recommendation — HIGH severity + MEDIUM confidence, or MEDIUM + HIGH. Clear vulnerability pattern, may need context verification (confidence >= MEDIUM)
• [Question]: Seeks clarification — potential vulnerability depending on context, intent unclear (confidence >= MEDIUM)
• [Nit]: Minor hardening suggestion, optional — max 2 per review
• [Praise]: Acknowledge good security practice — max 1 per review

Phase 4 — Per-Finding Haiku Verification

After Phase 3 identifies candidate findings, launch N parallel Haiku agents (one per finding) for independent verification.

Each Haiku agent receives:

• The finding description, severity, confidence, category, and CWE
• The relevant diff section around the flagged code
• The framework/sanitizer context discovered in Phase 1

Each agent verifies:

1. Data flow reachability — Can user input actually reach the vulnerable sink?
2. Sanitizer presence — Are there sanitizers/validators in the path that the main analysis missed?
3. Framework handling — Does the framework's security model prevent this exploit?
4. False positive patterns — Does this match any hard exclusion or precedent from WORKFLOW.md?

Each agent returns a verdict:

• KEEP — Finding confirmed. Data flow verified, no sanitizers found, exploit path is valid.
• DISMISS — False positive. Reason: {specific evidence — framework handling, sanitizer found, etc.}
• DOWNGRADE — Valid but lower severity or confidence. Reason: {what changed — e.g., only reachable by admins, mitigating control exists.}

Apply verdicts: remove DISMISSED findings, adjust DOWNGRADED findings' severity/confidence. Remaining findings proceed to report.

If a Haiku verification agent fails for a finding, default to KEEP (conservative — finding stays).

See WORKFLOW.md for the Haiku verification prompt template and verdict criteria.

Output Format

For each vulnerability found:

### [Triage] Vuln N: {Category Code}: `{file}:{line}`

* **Severity**: {CRITICAL|HIGH|MEDIUM}
* **Confidence**: {HIGH|MEDIUM}
* **Category**: {OWASP A0X:2025 or API/LLM Top 10}
* **CWE**: CWE-XXX
* **Description**: {What the vulnerability is and how it can be exploited}
* **Exploit Scenario**: {Specific attack path with example payload}
* **Recommendation**: {Concrete fix with code example}

Phase 5 — Report Generation

1. Create output directory using Bash: mkdir -p {output-directory}
2. Save the report to: {output-directory}/{YYYY-MM-DD}_{HH-MM-SS}_security-review.md

Include this header:

# Security Review R