Skillet Security Sweep

Use when asked to security-audit a repository, find vulnerabilities to fix, check for leaked secrets, review dependencies for known CVEs, or harden a project before exposure. Defensive find-and-fix only.

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.