Security Sweep

A security sweep is a time-boxed hunt through a codebase for the vulnerability classes that actually ship: unvalidated input reaching an interpreter, secrets in the tree, broken authorization, unsafe defaults. This skill runs that hunt methodically — by entry point and by data flow, not by scrolling files — and reports findings with severity, evidence, and a concrete fix. It is honest about what a static read cannot prove and says where dynamic testing must take over.

When to use this skill

• Before a public release, a penetration test, or a compliance review
• After inheriting a codebase whose security posture is unknown
• When a dependency alert or an incident prompts "what else of this kind do we have?"
• Periodic hygiene on services that accept input from outside the trust boundary

Workflow

1. Map the attack surface first. Enumerate entry points: HTTP routes and handlers, message consumers, scheduled jobs reading external data, file uploads, CLI arguments in privileged tools. The sweep is organized around this list; anything unlisted is out of scope by decision, not by oversight.
2. Trace input to interpreters. For each entry point, follow user-controlled data to every place it meets an interpreter: SQL, shell, HTML templates, path resolution, deserialization, regex construction, header emission. Flag any hop where validation or encoding is absent, and name the injection class it exposes.
3. Audit the authentication and authorization seams. Which routes skip the auth middleware, and is each skip intentional? Where is object ownership checked — in every handler, or hopefully somewhere upstream? Look specifically for fetch-by-identifier patterns with no tenant or owner filter.
4. Hunt stored secrets. Sweep the tree for keys, tokens, connection strings, and default passwords: config files, sample env files, test fixtures, generated docs. Verify the example env file contains placeholders, not real values that once worked.
5. Check the trust of defaults: debug endpoints reachable in production builds, permissive cross-origin policy, cookies missing secure attributes, verbose error pages leaking stack traces, admin accounts created by migrations or seed scripts.
6. Review dependency posture. Flag dependencies pinned to known-vulnerable ranges and any install-time script execution from packages that do not need it. Note whether a lockfile exists at all — an unpinned tree makes every other finding softer.
7. Write findings as evidence, severity, fix — one finding per root cause. Ten call sites of one unsafe helper is one finding with ten locations, not ten findings.

Output format

[CRITICAL|HIGH|MEDIUM|LOW] <one-line title>
  Where: <file:line, or list of locations>
  Evidence: <the code path — source of input, missing control, sink>
  Impact: <what an attacker gains, in one sentence>
  Fix: <specific change; name the safe API or pattern to use instead>

Close the report with the honest residue: scope actually covered, entry points not reviewed, and checks that require a running system (rate limiting, session fixation, real TLS configuration).

Guardrails

• Severity reflects exploitability and blast radius, not cleverness. A hardcoded production credential outranks an exotic theoretical injection.
• Never report a pattern match as a vulnerability without tracing reachability; dead code with a scary string is a note, not a finding.
• Do not paste live secret values into the report — reference their location and lead with rotation guidance.
• No exploit payloads beyond the minimum needed for a maintainer to reproduce the finding.
• If a category turns up nothing, report that the category was searched and how; silence and absence are different results.