Security Audit

Systematic security review of codebase. Covers source code, deps, config/secrets, infrastructure-as-code. Output: concise, deduplicated, severity-ranked report in chat — no file unless user asks.

Workflow

1. Scope target. Find root path to scan (user path, or cwd/repo if unspecified — ask only if ambiguous, e.g. multiple unrelated repos). Detect stack: language(s), frameworks, package managers, Docker/Terraform/K8s/CI config.
2. Scan in passes, using references/checklist.md for concrete patterns per category:
   • Source code — injection flaws, auth/session issues, unsafe deserialization, path traversal, SSRF, weak crypto, insecure error handling.
   • Secrets & hardcoded credentials — API keys, passwords, tokens, private keys, connection strings anywhere in tracked files (config, .env committed by mistake, code comments).
   • Dependencies — parse manifest/lockfiles (package.json/package-lock.json, requirements.txt/poetry.lock, *.csproj/packages.lock.json, go.mod, pom.xml, etc). Flag known-vulnerable or abandoned/unpinned versions. Web search for CVE lookups on suspect packages/versions; else flag "needs CVE verification", not guessing.
   • Config & IaC — Dockerfiles, docker-compose, Terraform, Kubernetes manifests, CI/CD pipelines, nginx/apache configs, cloud policy files. Watch permissive access, exposed ports/services, root containers, plaintext secrets, disabled TLS verification, wildcard permissions.
3. Deduplicate before reporting. Same root cause repeats across files (vulnerable dep in 12 places, copy-pasted unsafe pattern) → report once as single finding listing all affected locations — never repeat explanation per occurrence. Hard requirement, not style.
4. Assign severity using rubric below. Consistent; don't inflate or downplay.
5. Write report in chat per format below. Skip empty severity sections (omit, not "No findings"), note total categories scanned at top.

Severity rubric

Report format

# Security Audit — <scope>

Scanned: <n files/dirs>, categories: code / secrets / dependencies / config & IaC
Findings: X Critical, Y High, Z Medium, W Low, V Info

## Critical
### <Short title>
- **Where:** file:line (list all locations if repeated)
- **Issue:** one or two sentences, no boilerplate
- **Impact:** one sentence
- **Fix:** concrete, actionable

## High
...

Each finding tight: 4 lines max unless genuinely complex. No repeated preambles — say once per finding. Category scanned with zero findings → don't list in body; summary line covers it.

When context is large

Big repos: don't read every file verbatim into context. Prioritize: entry points (routes/controllers), auth code, user-input handling, config/env files, IaC files, manifest/lockfiles. Use grep/search for known-risky patterns (see checklist) before deep-reading, then read only hits with surrounding context.

After the report

Offer, don't push: "Want me to go deeper on any of these, or help fix the Critical/High ones first?" Don't generate a file unless asked.