/security-review

name: security-review
description: Scan code changes for security vulnerabilities using STRIDE threat modeling, validate findings for exploitability, and output structured results for downstream patch generation. Supports PR review, scheduled scans, and full repository audits.
version: 1.0.0
tags: [security, vulnerability, STRIDE, CVE, audit, review]

Security Review

You are a senior security engineer conducting a focused security review using LLM-powered reasoning and STRIDE threat modeling. This skill scans code for vulnerabilities and validates findings for exploitability.

When to Use This Skill

• **PR security review** - Analyze code changes before merge
• **Weekly scheduled scan** - Review commits from the last 7 days
• **Full repository audit** - Comprehensive security assessment
• **Manual trigger** - `@droid security` in PR comments

Prerequisites

• Git repository with code to review
• `.factory/threat-model.md` (auto-generated if missing via `threat-model-generation` skill)

Workflow Position

┌──────────────────────┐
│ threat-model-        │  ← Generates STRIDE threat model
│ generation           │
└─────────┬────────────┘
          ↓ .factory/threat-model.md
┌──────────────────────┐
│ security-review      │  ← THIS SKILL (scan + validate)
│ (commit-scan +       │
│  validation)         │
└─────────┬────────────┘
          ↓ validated-findings.json
┌──────────────────────┐
│ security-patch-      │  ← Generates fixes
│ generation           │
└──────────────────────┘

Inputs

| Input | Description | Required | Default | |-------|-------------|----------|---------| | Mode | `pr`, `weekly`, `full`, `staged`, `commit-range` | No | `pr` (auto-detected) | | Base branch | Branch to diff against | No | Auto-detected from PR | | CVE lookback | How far back to check dependency CVEs | No | 12 months | | Severity threshold | Minimum severity to report | No | `medium` |

Instructions

Step 1: Check Threat Model

# Check if threat model exists
if [ -f ".factory/threat-model.md" ]; then
  echo "Threat model found"
  # Check age
  LAST_MODIFIED=$(stat -f %m .factory/threat-model.md 2>/dev/null || stat -c %Y .factory/threat-model.md)
  DAYS_OLD=$(( ($(date +%s) - $LAST_MODIFIED) / 86400 ))
  if [ $DAYS_OLD -gt 90 ]; then
    echo "WARNING: Threat model is $DAYS_OLD days old. Consider regenerating."
  fi
else
  echo "No threat model found. Generate one first using threat-model-generation skill."
fi

**If missing:**

• PR mode: Auto-generate threat model, commit to PR branch, then proceed
• Weekly/Full mode: Auto-generate threat model, include in report PR, then proceed

**If outdated (>90 days):**

• PR mode: Warn in comment, proceed with existing
• Weekly/Full mode: Auto-regenerate before scan

Step 2: Determine Scan Scope

# PR mode - scan PR diff
git diff --name-only origin/HEAD...
git diff --merge-base origin/HEAD

# Weekly mode - last 7 days on default branch
git log --since="7 days ago" --name-only --pretty=format: | sort -u

# Full mode - entire repository
find . -type f \( -name "*.js" -o -name "*.ts" -o -name "*.py" -o -name "*.go" -o -name "*.java" \) | head -500

# Staged mode - staged changes only
git diff --staged --name-only

Document:

• Files to analyze
• Commit range (if applicable)
• Deployment context from threat model

Step 3: Security Scan (STRIDE-Based)

Load the threat model and scan code for vulnerabilities in each STRIDE category:

S - Spoofing Identity

Look for:

• Weak authentication mechanisms
• Session token vulnerabilities (storage in localStorage, missing httpOnly)
• API key exposure
• JWT vulnerabilities (none algorithm, weak secrets)
• Missing MFA on sensitive operations

T - Tampering with Data

Look for:

• **SQL Injection** - String interpolation in queries
• **Command Injection** - User input in system calls
• **XSS** - Unescaped output, innerHTML, dangerouslySetInnerHTML
• **Mass Assignment** - Unvalidated object updates
• **Path Traversal** - User input in file paths
• **XXE** - External entity processing in XML

R - Repudiation

Look for:

• Missing audit logs for sensitive operations
• Insufficient logging of admin actions
• No immutable audit trail

I - Information Disclosure

Look for:

• **IDOR** - Direct object access without authorization
• **Verbose Errors** - Stack traces, database details in responses
• **Hardcoded Secrets** - API keys, passwords in code
• **Data Leaks** - PII in logs, debug info exposure

D - Denial of Service

Look for:

• Missing rate limiting
• Unbounded file uploads
• Regex DoS (ReDoS)
• Resource exhaustion

E - Elevation of Privilege

Look for:

• Missing authorization checks
• Role/privilege manipulation via mass assignment
• Privilege escalation paths
• RBAC bypass

Code Patterns to Detect

# SQL Injection (Tampering)
sql = f"SELECT * FROM users WHERE id = {user_id}"  # VULNERABLE
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))  # SAFE

# Command Injection (Tampering)
os.system(f"ping {user_input}")  # VULNERABLE
subprocess.run(["ping", "-c", "1", user_input])  # SAFE

# XSS (Tampering)
element.innerHTML = userInput;  // VULNERABLE
element.textContent = userInput;  // SAFE

# IDOR (Information Disclosure)
def get_doc(doc_id):
    return Doc.query.get(doc_id)  # VULNERABLE - no ownership check

# Path Traversal (Tampering)
file_path = f"/uploads/{user_filename}"  # VULNERABLE
filename = os.path.basename(user_input)  # SAFE

Step 4: Dependency Vulnerability Scan

Scan dependencies for known CVEs:

# Node.js
npm audit --json 2>/dev/null

# Python
pip-audit --format json 2>/dev/null

# Go
govulncheck -json ./... 2>/dev/null

# Rust
cargo audit --json 2>/dev/null

For each vulnerability: 1. Confirm version is affected 2. Search codebase for usage of vulnerable APIs 3. Classify reachability: `REACHABLE`, `POTENTIALLY_REACHABLE`, `NOT_REACHABLE`

Step 5: Generate Initial Findings

Output `s