security-sweep
A defensive security audit of a repository: find what an attacker could use, report how to fix it. Every finding ships with its remediation; nothing in the report teaches exploitation beyond what is needed to verify the fix.
Read-only, with one exception: never copy, log, or echo discovered secret values anywhere, including the report. Reference secrets by file:line and type only.
Lenses
| Lens | Hunting for |
|---|---|
| Secrets | Credentials, tokens, API keys, private keys in the working tree AND full git history (git log --all -p with pattern grep); high-entropy strings in config |
| Dependencies | Known CVEs (npm audit, pip-audit, govulncheck, cargo audit as applicable), abandoned packages, pinning hygiene, lockfile present |
| Input handling | Injection surfaces (SQL, shell, path traversal, template), missing validation at trust boundaries, unsafe deserialization |
| AuthN/AuthZ | Unprotected routes and endpoints, missing authorization checks distinct from authentication, weak hashing, session handling |
| Exposure | Destructive endpoints reachable without auth (a DELETE route an agent or crawler can hit), debug modes, verbose errors leaking internals, internal hostnames/private IPs/PII in code and docs |
Lens guidance:
- Secrets in history are findings even when the tree is clean; remediation is rotation first, history rewrite second (the publish-readiness skill has the full rewrite recipe).
- For exposure, think about non-human callers too: anything with an OpenAPI spec and an unprotected destructive route will eventually be called by an automated agent.
Verification
Confirm before reporting: trace the path from untrusted input to the sink, or confirm the dependency version is actually in the resolved lockfile, or confirm the route really lacks the auth middleware (read the router, not just the handler). Findings that depend on configuration you cannot see get (unverified) and one severity lower. Do not write exploit payloads to prove findings; a traced code path is the proof.
Report contract
Same spine as line-check and bug-hunt. Severity: critical (exploitable now: leaked live credential, unauthenticated destructive endpoint, injection on a reachable path) / high (exploitable with common conditions) / medium (defense-in-depth gap) / low (hardening) / info. Effort: S / M / L.
# security-sweep report: <repo> (<date>)
## Verdict
Paragraph: overall posture, the single scariest confirmed finding,
and anything needing same-day action (credential rotation goes here).
## Scorecard
| Lens | Score (0-5) | Summary |
## Findings
### [SEVERITY] Short imperative title
- **Lens:** which lens found it
- **Where:** file:line (for secrets: location and type, never the value)
- **What:** the weakness, concretely
- **Why it matters:** what an attacker gains
- **Fix:** specific remediation, with commands where short
- **Effort:** S / M / L
## Backlog
Numbered, leverage-sorted: `N. [SEVERITY/EFFORT] title (lens)`
## Not checked
Skipped lenses/areas and why (e.g., no runtime to test, config not in repo).
Common mistakes
- Echoing a discovered secret into the report. The report gets shared; now it leaked twice.
- Reporting a CVE in a dependency that the lockfile does not actually resolve.
- Treating "rotate the credential" as optional when a secret is in a public repo's history. Rotation is the fix; the history rewrite is cleanup.
- Grading authentication present as authorization done. Logged-in is not allowed-to.
- Severity inflation. A hardening suggestion reported as critical erodes trust in the report.