Vulnerability Scanner

---
name: security-vuln-scanner
description: |
  Trigger when the user asks to scan for security vulnerabilities, audit a
  codebase for security issues, check CVE status of dependencies, or run
  a security review. Phrases: "security scan", "vuln audit", "security review",
  "CVE check", "audit dependencies".
allowed-tools:
  - Read
  - Grep
  - Bash(npm audit *)
  - Bash(pnpm audit *)
  - Bash(snyk *)
  - Bash(semgrep *)
---

# Security Vulnerability Scanner

Audit a codebase for known CVEs in dependencies and common application
vulnerabilities in first-party code. Produce a report ranked by exploitability.

## Prerequisites

- Package manager locked (pnpm-lock, package-lock, or requirements.txt)
- `npm audit`, `pnpm audit`, or `snyk` available
- Optional: `semgrep` installed for SAST scanning

## Steps

1. **Dependency audit first (fastest signal):**
   ```bash
   pnpm audit --prod --json > deps-audit.json
   ```
   Parse and bucket by severity: CRITICAL, HIGH, MODERATE, LOW.

2. **For every HIGH/CRITICAL, determine:**
   - Is the vulnerable code path actually reachable from your entry points?
   - Is there a patched version?
   - Can you update, or do you need to fork / pin / accept risk?

3. **SAST scan for first-party code.** Use semgrep with the default ruleset:
   ```bash
   semgrep --config auto src/ > sast-report.json
   ```
   Common finds:
   - SQL injection via string interpolation
   - XSS via innerHTML / dangerouslySetInnerHTML
   - Hardcoded secrets
   - Insecure randomness (Math.random for tokens)
   - Open redirects

4. **Secret scan via gitleaks or similar:**
   ```bash
   gitleaks detect --source . --redact
   ```
   False positive rate is meaningful; skim manually, do not just accept blindly.

5. **Produce a three-section report:**
   - **Ship-blockers** (critical CVEs in prod deps, RCE findings, exposed secrets)
   - **This sprint** (high severity, exploitable user-input paths)
   - **Backlog** (moderate, low exploitability)

6. **Track suppressions explicitly.** If you accept a risk, document it in
   `security/accepted-risks.md` with reason and review date. Never silently
   ignore a finding.

## Common real findings worth looking for

- `dangerouslySetInnerHTML` with user-controlled input
- `JSON.parse` of user-controlled input (prototype pollution on old Node)
- SSRF via server-side fetch with user-controlled URLs
- CORS configured too permissive (`*`)
- Auth checks in middleware but not in API routes

## Output

- `security-scan.md` report with findings bucketed by severity
- PR that fixes ship-blockers and high-severity issues
- `accepted-risks.md` for anything deferred