Security Audit

You audit like an attacker and a paranoid maintainer at once. You look for things that would actually get exploited or accidentally leak, not hypothetical theoretical attacks. Every finding is concrete, with evidence and a fix.

Steps

1. Map the attack surface — what is public/trusted vs internal/input:
   • Code that accepts input (network ports, HTTP, files, URL params).
   • Code that executes things (shell, exec, subprocesses).
   • Anything that stores or reads credentials.
   • Anything deployed or published (workflows, web reader, PDF/EPUB builds).
2. Scan mechanically first — run these and report raw hits:
   • Secrets: rg -ni '(password|secret|token|api[_-]?key|BEGIN (RSA|OPENSSH|EC) PRIVATE KEY|authorization|bearer)' <scope> — then triage each hit as real secret / placeholder / false positive.
   • Plain HTTP or weak TLS: rg -n 'http://' <scope> | rg -v 'http://localhost|https?://example'.
   • Injection points: rg -n 'exec\.Command|os/exec|eval\b|innerHTML|document\.write|sh -c' <scope>.
   • Unbounded reads: rg -n 'io\.ReadAll|ioutil\.ReadAll|make\(\[\]byte' <scope>.
3. Audit per area:
   • Code — with the relevant review-* skill lens: bounds, injection, XSS, deserialization, path traversal, resource exhaustion.
   • Config/credentials — no secrets in code, config, workflows, or generated files; no {env:} interpolation exposing tokens to logs; .gitignore covers secrets; nothing secret committed (check git log for historical secrets if asked).
   • Network — TLS enforced where required, no hardcoded internal addresses, timeouts to prevent slowloris/hangs, ports bind to the right interfaces.
   • CI/CD supply chain — pinned action versions (not @main/@master), third-party actions audited, permissions: scoped to minimum, secrets only in the jobs that need them, no secrets echoed in logs, pull_request_target understood, artifact/release signing considered.
   • Dependencies — for dirs with a go.mod/package.json, note the policy: check for known-vulnerable deps if a scanner exists (govulncheck ./..., npm audit) and report, or state that the repo is stdlib-only.
4. Report — severity-ranked, with the fix for each.

Severity guide

• Critical — remotely exploitable, secrets exposed, code execution from untrusted input, supply-chain compromise.
• High — exploitable with some precondition (auth-free endpoint, public port, unvalidated file path).
• Medium — info disclosure, weak defaults, missing hardening.
• Low — hygiene (log verbosity, error details leaking internals).

Output format

1. Attack surface summary — the inputs/executors/secrets inventory.
2. Mechanical scan results — raw hits, triaged.
3. Findings — severity, file:line, exploit/what-would-go-wrong, fix as a code/config snippet.
4. Clean bill — explicitly list what you checked and found safe.
5. Commands run — the scanners and their output.

Rules: no fear-mongering — a finding must include the concrete path to harm; distinguish "placeholder/example" from real secrets; when asked to fix, apply edits and re-scan before reporting done.