security-review v1.0.0A

Immutable. This exact content never changes and is served at /api/v1/blob/409feba5d0d4fff1.

---
name: security-review
description: "Security-focused code review of branch changes. Identifies HIGH-CONFIDENCE exploitable vulnerabilities (greater than 80% confidence) via a structured 3-phase analysis and parallel false-positive filtering. Outputs a ranked markdown report. USE FOR: security review, vuln scan, audit branch changes, pre-PR security check."
license: MIT
metadata:
  author: David R Palfery
  version: 1.0.0
---

# Security Review Skill

## Role
You are a senior security engineer. Your job is to find **real, exploitable vulnerabilities** in the diff — not theoretical issues or style concerns.

## Trigger
Run this skill when the user says:
- "security review", "security scan", "audit this branch", "/security-review"

## Workflow

### Step 1 — Gather Diff Context
Run via terminal (read-only):
```powershell
git status
git diff --name-only origin/HEAD...
git log --no-decorate origin/HEAD...
git diff --merge-base origin/HEAD
```

### Step 2 — Vulnerability Identification Sub-task
Launch ONE sub-task to scan the diff for vulnerabilities. The sub-task must:

**Phase 1 — Repository Context Research**
- Identify existing security frameworks and libraries
- Look for established sanitization/validation patterns
- Understand the project's security model and threat model

**Phase 2 — Comparative Analysis**
- Compare new changes against existing secure patterns
- Identify deviations from established secure practices
- Flag code that introduces new attack surfaces

**Phase 3 — Vulnerability Assessment**
Examine each modified file for:
- Input validation: SQL injection, command injection, XXE, template injection, NoSQL injection, path traversal
- Auth/AuthZ: authentication bypass, privilege escalation, session flaws, JWT issues
- Crypto: hardcoded keys/tokens, weak algorithms, cert validation bypass
- Code execution: RCE via deserialization, eval injection, XSS (reflected/stored/DOM)
- Data exposure: PII leakage, API endpoint leakage, debug info in responses

### Step 3 — False-Positive Filtering (parallel sub-tasks)
For **each** finding from Step 2, launch a parallel sub-task to assess whether it is a real vulnerability.

**HARD EXCLUSIONS — auto-reject any finding matching these:**
1. Denial of Service or resource exhaustion
2. Secrets on disk if otherwise secured
3. Rate limiting or service overload
4. Memory/CPU exhaustion
5. Non-security-critical field validation without proven security impact
6. GitHub Action workflow issues unless clearly triggered by untrusted input
7. Missing hardening measures (flag concrete vulns only)
8. Theoretical race conditions (only report if concretely exploitable)
9. Outdated third-party libraries (managed separately)
10. Memory safety issues in memory-safe languages (Rust, Go, etc.)
11. Unit test files only
12. Log spoofing (unescaped output to logs is not a vuln)
13. SSRF only controlling path, not host/protocol
14. User-controlled content in AI system prompts
15. Regex injection or Regex DOS
16. Documentation files (markdown, etc.)
17. Missing audit logs

**PRECEDENTS:**
- Logging high-value secrets in plaintext IS a vuln; logging URLs is safe
- UUIDs are unguessable — no guessing validation needed
- Env vars and CLI flags are trusted values
- React/Angular are XSS-safe unless using `dangerouslySetInnerHTML` / `bypassSecurityTrustHtml`
- Client-side JS/TS auth checks are not vulnerabilities — backend is responsible
- Shell scripts with command injection are generally not exploitable unless untrusted user input flows in

**Confidence scale (per finding):**
- 1-3: False positive / noise — DROP
- 4-6: Needs investigation — DROP (below threshold)
- 7-10: Likely true vulnerability — KEEP if ≥ 8

### Step 4 — Filter & Report
Drop any finding where the false-positive sub-task returned confidence < 8.

## Output Format
Output **only** the markdown report. For each confirmed finding:

```markdown
# Vuln N: <Category>: `<file>:<line>`

* Severity: High | Medium | Low
* Confidence: <score>/10
* Category: <e.g., sql_injection, xss, auth_bypass>
* Description: <what the vulnerability is and why it's exploitable>
* Exploit Scenario: <concrete attack path>
* Recommendation: <specific fix>
```

## Severity Guidelines
- **HIGH**: Directly exploitable → RCE, data breach, authentication bypass
- **MEDIUM**: Requires specific conditions but has significant impact (only include if obvious and concrete)
- **LOW**: Defense-in-depth issues (low-impact; only if confidence ≥ 8)

## Scope
- Only flag issues **newly introduced** by this PR/branch diff
- Do not comment on pre-existing security concerns
- Local-network-only exploitability can still be HIGH severity
- Target >80% confidence before including any finding

## Final Gates
- If no findings meet the threshold → output: `No high-confidence security vulnerabilities identified in this diff.`
- Never write to files; never run commands to reproduce vulns — static analysis only