security-auditlisted

# Security Audit Review code and config for common security issues so risks are identified and remediated. ## When to Activate - User asks for "security review", "security audit", or "check for vulnerabilities" - Before a release or after adding auth, payments, or sensitive data handling - Reviewing new or changed endpoints, file handling, or configuration - After adding a new dependency or external integration ## Work Process 1. **Define scope** — Files or area to review (e.g. changed files in PR, auth module, payment flow). Focus on high-risk areas first. 2. **Detect the stack first** — Indicator files (`package.json`, `requirements.txt`, `go.mod`, framework configs) tell you which checks matter and which framework mitigations apply, before scanning. 3. **Check each category** — Injection, secrets, auth/authz, sensitive data, dependencies, config, LLM. Use the checklists below. Trace high-value leads as source→sink data flow (taint chains): a secret reaching a network sink, a file read reaching a network sink, or external input reaching a code-exec sink is a finding of its own, distinct from "a secret is present". 4. **Gate findings by confidence** — Report a finding only when the vulnerable pattern AND attacker-controlled input are both confirmed by reading the code. Medium-confidence items go to a separate "Needs verification" section with the specific open question. "Potentially" or "theoretically" in a finding means it is not one yet — every reported issue needs a