awesome-security-audit

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 touches a live system or a package registry. Note the mode: this skill is white-box static review; dynamic and runtime issues are out of its reach (see Scope and limitations). Focus high-risk areas first.
2. Plan, then gate active steps — Propose the active-scan plan (which scanners, which commands) and wait for approval before running it; passive code and config reading needs no approval. If authorization for an active step is missing, stay passive and say what that leaves unverified. Before recommending or running any scanner, confirm it exists at a known version (semgrep --version, exit 0) — an assumed-installed tool and an installed one produce different plans; where a tool is absent, mark that gate unavailable rather than skipping it silently.
3. Detect the stack — Indicator files (package.json, requirements.txt, go.mod, framework configs) tell you which checks matter and which framework mitigations apply, before scanning.
4. Work the surface in order — Attack-surface map (enumerate endpoints, inputs, trust boundaries, external integrations) → passive HTTP/config analysis → authentication and authorization model → tenant and object-ownership boundaries → business-logic abuse. Within each phase use the category checklists in references/checklists.md — load that file first; it is the working checklist. 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".
5. 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 concrete attacker, input, and result. Defense-in-depth suggestions go to a "Hardening notes" section, never into findings. Keep a candidate worklist — every grep hit and scanner line driven to an explicit verdict (confirmed / traced-safe / needs-PoC), never eyeballed-and-forgotten — and run each confirmed candidate through the restate-the-claim, adversarial-revalidation, and already-fixed checks in references/verification.md before it enters the report.
6. Design-intent gate — Before flagging a boundary as unhandled, check whether the code explicitly returns/rejects there (errors.New("cache full"), HTTP 429, buffer-full reject). An explicit designed return is not a bug; a panic/crash at the boundary still is. Deduplicate a repeated pattern into one finding with a count, not N findings.
7. Escalate criticals immediately — Don't hold a confirmed Critical (RCE, auth bypass, exposed live secret, bulk-PII exposure) for the final report; surface it to the user the moment it's confirmed, with the immediate containment step.
8. Sweep for variants — a confirmed finding is a class, not an instance. Before writing it up, search the repo for the same shape: the same sink reached from a different caller, the same missing check on sibling routes, the same pattern copy-pasted into another module. Grep the sink, the vulnerable call, and the fix's absence (execute(f" after finding one f-string query; every route file after finding one without an ownership check), then read each hit in context. Report the class as one finding listing every location; split it out only where a variant's severity or reachability genuinely differs. Fixing the one caller the report named and leaving four siblings live is the failure this step exists to prevent.
9. Document findings — Location (file:line or area), issue, impact, and recommended fix. Do not claim "secure"; frame as "no obvious issues in reviewed scope" and suggest further steps (e.g. dependency scan, pentest) if relevant.
10. Specify the remediation — Describe the concrete fix per finding; do not apply it, and do not introduce new secrets or log sensitive data in what you propose.
11. Stop on impact — If an active step shows signs of affecting the running system or its data (errors, state changes, account lockouts), stop that step and report before continuing.