Scan skills in a project directory for security issues and generate a markdown table report, then install skills from a local registry. Combines static analysis of code and markdown files with supply chain checks. Use when auditing a skills directory, generating a security summary table, or installi
Security
Skillet Security Sweep
Try itUse when asked to security-audit a repository, find vulnerabilities to fix, check for leaked secrets, review dependencies for known CVEs, or harden a project...
What it does
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.
The skill document
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: ()
## 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.
Related skills
Use when asked what to build next, what features a repo is missing, where the opportunities are, or to suggest a direction or roadmap grounded in the code. T...
Git Security Scanner & Repo Health Auditor — entropy-based secret detection, composite health scoring, commit quality analysis, stale branch cleanup, and dep...
Use when asked to simplify, clean up, tidy, or refactor code for clarity without changing what it does, or when the user says "simplify this", "clean this up...
Use when code review feedback arrives - from a human reviewer, a bot, or a review agent - before implementing any of it. Especially when the feedback is part...
Use before making a private repository public, before the first push of a new public repo, or when the user asks "is this safe to publish", "check for leaks"...