awesome-security-auditlisted

# Security Audit Review code and config for common security issues so risks are identified, evidenced, and handed over with the fix each one needs. Read-only on the codebase: it reports findings and the remediation each calls for, and never applies an edit. The active phase (scanners, `npm audit`, registry lookups) is gated separately in step 2 and reads — it does not write either. A security fix belongs to whoever owns the code path, reviewed against the finding that motivated it; an audit that silently patches what it found leaves nobody able to check whether the patch closed the hole or moved it. ## 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 Split the work into a passive phase (reading source, config, and dependency manifests — no gate) and an active phase (running scanners, `npm audit`/`pip audit`, dependency resolution that reaches a registry, or any dynamic/network probe — behind the approval gate in step 2). Default to passive. 1. Confirm scope, authorization, and mode — Pin down what is in scope and explicitly out of scope (exact origin, `/api`, specific modules, test accounts vs real data). Confirm the user owns or is authorized to test the target — required before any active command tou