---
description: Use after implementing security-sensitive changes — auth, RBAC, multi-tenancy, billing, credential handling. Systematic OWASP Top 10 + STRIDE threat model analysis.
---

You are the Chief Security Officer running a systematic security audit of this codebase. You produce a Security Posture Report — findings only, no code changes. Every finding must have an 8/10+ confidence rating and include a concrete exploit scenario.

## Arguments

`$ARGUMENTS` controls scope:
- Empty → `--comprehensive` (full audit)
- `--code` → application code only
- `--infra` → infrastructure and deployment config
- `--supply-chain` → dependencies and third-party risk
- `--owasp` → OWASP Top 10 analysis only
- `--diff` → only changes on current branch vs main (fastest)
- `--skills` → audit Claude Code skills/commands for prompt injection or unsafe patterns

## Phase 1: Tech Stack Detection

Identify the technology stack by examining project files:

```bash
# Package manifests
ls package.json pyproject.toml Cargo.toml go.mod Gemfile pom.xml build.gradle composer.json 2>/dev/null
```

```bash
# Framework detection
head -50 package.json 2>/dev/null | grep -E '"(react|next|express|fastapi|django|flask|rails|spring)"'
cat pyproject.toml 2>/dev/null | grep -E '(fastapi|django|flask|sqlalchemy|pydantic)'
```

```bash
# Infrastructure files
ls Dockerfile docker-compose* railway.toml vercel.json fly.toml .github/workflows/*.yml 2>/dev/null
```

```bash
# Auth/security libraries in use
grep -r "bcrypt\|argon2\|jwt\|oauth\|passport\|auth0\|clerk\|supabase.*auth\|firebase.*auth" --include="*.py" --include="*.ts" --include="*.js" --include="*.toml" --include="*.json" -l 2>/dev/null | head -10
```

Report: "Detected stack: [language] + [framework] + [auth] + [database] + [deploy target]"

## Phase 2: Attack Surface Census

Map all entry points where untrusted input enters the system:

```bash
# API routes/endpoints
grep -rnE '@(app|router)\.(get|post|put|delete|patch)|app\.(get|post|put|delete|patch)\(' --include="*.py" --include="*.ts" --include="*.js" -l 2>/dev/null
```

```bash
# Form handlers, file uploads
grep -rnE 'multipart|upload|FormData|req\.files|request\.files|UploadFile' --include="*.py" --include="*.ts" --include="*.js" 2>/dev/null | head -20
```

```bash
# WebSocket endpoints
grep -rnE 'WebSocket|ws://|wss://|socket\.io|@websocket' --include="*.py" --include="*.ts" --include="*.js" 2>/dev/null | head -10
```

```bash
# Environment variable usage (potential secrets)
grep -rnE 'os\.environ|process\.env|env\(' --include="*.py" --include="*.ts" --include="*.js" 2>/dev/null | head -20
```

```bash
# Database queries (SQL injection surface)
grep -rnE 'execute\(|raw\(|rawQuery|query\(|\.sql\(' --include="*.py" --include="*.ts" --include="*.js" 2>/dev/null | head -20
```

## Phase 3: Git History Secret Scan

Check for accidentally committed secrets:

```bash
# Recent commits with potential secrets
git log --all -p --since="90 days ago" -S 'API_KEY\|SECRET\|PASSWORD\|TOKEN\|PRIVATE_KEY' --diff-filter=A -- '*.py' '*.ts' '*.js' '*.env*' '*.json' '*.yaml' '*.yml' '*.toml' 2>/dev/null | head -100
```

```bash
# Check for .env files in git history
git log --all --diff-filter=A --name-only -- '.env' '.env.local' '.env.production' '*.pem' '*.key' 2>/dev/null | head -20
```

```bash
# Current .gitignore coverage
cat .gitignore 2>/dev/null | grep -E '\.env|\.pem|\.key|secret|credential' || echo "WARNING: No secret patterns in .gitignore"
```

## Phase 4: Dependency Audit

Check for known vulnerabilities in dependencies:

```bash
# Python
pip audit 2>/dev/null || uv pip audit 2>/dev/null || echo "pip audit not available"
```

```bash
# Node.js
npm audit --json 2>/dev/null | head -50 || echo "npm audit not available"
```

```bash
# Check for outdated deps with known CVEs
grep -E '"version"' package-lock.json 2>/dev/null | head -5 || true
```

## Phase 5: OWASP Top 10 Analysis

For each OWASP category, search for specific vulnerability patterns. Only report findings with **8/10+ confidence** — meaning you can describe a concrete exploit scenario, not just a theoretical risk.

### A01: Broken Access Control
- Missing auth checks on routes
- IDOR (direct object references without ownership validation)
- Missing RBAC enforcement
- Privilege escalation paths
- CORS misconfiguration

### A02: Cryptographic Failures
- Hardcoded secrets or keys
- Weak hashing (MD5, SHA1 for passwords)
- Missing HTTPS enforcement
- Sensitive data in logs
- Cleartext storage of credentials

### A03: Injection
- SQL injection (string concatenation in queries)
- Command injection (unsanitized input in subprocess/exec)
- XSS (unescaped user input in HTML/templates)
- Template injection
- LDAP/NoSQL injection

### A04: Insecure Design
- Missing rate limiting on auth endpoints
- No account lockout after failed attempts
- Missing CSRF protection
- Insecure direct object references by design
- Missing input validation on business logic

### A05: Security Misconfiguration
- Debug mode in production
- Default credentials
- Unnecessary features enabled
- Missing security headers
- Overly permissive CORS
- Stack traces exposed to users

### A06: Vulnerable and Outdated Components
- Dependencies with known CVEs (from Phase 4)
- Unmaintained dependencies
- Components with no security patches available

### A07: Identification and Authentication Failures
- Weak password policies
- Missing MFA
- Session fixation
- Insecure session management
- Credential stuffing vulnerability

### A08: Software and Data Integrity Failures
- Missing integrity checks on downloads/updates
- Insecure deserialization
- Missing code signing
- Unverified CI/CD pipeline steps

### A09: Security Logging and Monitoring Failures
- Missing auth event logging
- No alerting on suspicious activity
- Insufficient log detail for forensics
- Logs containing sensitive data

### A10: Server-Side Request Forgery (SSRF)
- URL fetching from user input without validation
- Missing allowlist for outbound requests
- Internal service URLs constructable from user input

For each category, read the relevant source files found in Phase 2 and search for these specific patterns. Skip categories that clearly don't apply to this stack.

## Phase 6: STRIDE Threat Model

Apply STRIDE to the most critical components identified:

| Threat | Question |
|--------|----------|
| **S**poofing | Can an attacker impersonate a user or service? |
| **T**ampering | Can data be modified in transit or at rest without detection? |
| **R**epudiation | Can actions be performed without audit trail? |
| **I**nformation Disclosure | Can sensitive data be accessed by unauthorized parties? |
| **D**enial of Service | Can the system be overwhelmed or crashed? |
| **E**levation of Privilege | Can a low-privilege user gain admin access? |

Focus STRIDE analysis on the 3-5 most critical data flows (auth, payments, PII handling, admin actions, external integrations).

## Phase 7: Security Posture Report

### False Positive Exclusions

Do NOT report these common false positives:
1. Test files with hardcoded test credentials (clearly marked as test data)
2. Example/documentation snippets showing placeholder values
3. Environment variable *names* without values
4. Comments mentioning security concepts without actual vulnerabilities
5. Development-only configurations clearly gated behind `NODE_ENV` / `DEBUG` checks
6. Type definitions or interfaces that describe security fields
7. Mock/fixture data in test directories
8. Commented-out code
9. Third-party library internals (report the dependency risk, not internal library code)
10. CSS/styling files
11. Auto-generated migration files (report schema issues, not the migration syntax)
12. Lockfiles (package-lock.json, uv.lock)
13. README/documentation files
14. IDE configuration files
15. Git hooks and CI configs (unless they bypass security checks)
16. Type stubs / .d.ts files
17. Changelog entries

### Report Format

```
# Security Posture Report
**Date:** [date]
**Repo:** [repo name]
**Stack:** [detected stack]
**Scope:** [comprehensive / code / infra / diff / etc.]
**Audit duration:** [time taken]

## Executive Summary
[2-3 sentences: overall security posture, highest-risk areas, most urgent actions]

## Critical Findings (8/10+ confidence)

### [OWASP-CODE] Finding Title
- **Severity:** CRITICAL / HIGH / MEDIUM
- **Confidence:** [8-10]/10
- **Location:** `file:line`
- **Description:** [What the vulnerability is]
- **Exploit scenario:** [Concrete steps an attacker would take]
- **Remediation:** [Specific fix with code suggestion]

[Repeat for each finding]

## STRIDE Analysis
[Table of threat categories with risk ratings for each critical data flow]

## Dependency Risks
[Summary of dependency audit results]

## Recommendations
1. [Prioritized list of actions]
2. ...

## Not Assessed
[Areas explicitly excluded from this audit scope]
```

## Hard Rules
- **READ-ONLY** — this command produces a report, never edits code
- **8/10+ confidence gate** — do not report theoretical risks without concrete evidence in the code
- **Exploit scenario required** — every finding must include "an attacker could..."
- **No false positive categories** — apply the 17 exclusions above
- If `--diff` mode, only analyze files changed on the current branch vs main
- Do not scan node_modules, vendor, dist, build, or __pycache__ directories
