Security Scan

Security Scan

Trigger phrases: "security scan", "run a security scan", "OWASP check", "scan for vulnerabilities", "find security vulnerabilities", "security audit", "api key", "secret key", "leaked credential", "credentials leaked", "hardcoded secret", "hardcoded password", "sql injection", "can an attacker"

The core of a security vulnerability fits in a single sentence: an untrusted input reaches a dangerous operation without being adequately checked. This skill chases exactly that sentence — it first looks for where the input comes from, then where it flows, and what gate should sit in between. It is stack-agnostic: whatever the language/framework, the same logic applies; when current tooling and patterns are needed, it runs a web search.

Kit adaptation (local, .claude/): security-expert-csk applies this; findings are carried to review-agent-csk in severity order. It also holds for the default stack (.NET/PostgreSQL). Automatic fixes only with explicit approval (§4.4); .claude does not go to the repo (§4.3). §4 Prohibitions apply.

What it does, what it doesn't

• Does: surfaces common vulnerability classes, known vulnerable dependencies, and risky configuration; ties each finding to a concrete fix.
• Doesn't: does not replace a professional pentest / SAST / DAST. The report guides, it does not give full assurance — state this at the end of the report.
• Boundary: analysis is local; code/data is not sent to an external service, and the project directory is not left.

Mental model — source → gate → sink

Reduce every check to three questions:

1. Source — where does the input enter? (route, API endpoint, form, CLI argument, file upload, WebSocket, queue message, external API response)
2. Sink — which dangerous operation does this input reach? (SQL execution, shell, file path, HTML render, deserialization, template)
3. Gate — is there validation / parameterization / escaping / authorization in between? If not, that's the finding.

The scan applies this model on four fronts: dependency · code · configuration · authorization. The result is ranked by severity, and the fix is presented for the user to choose.

Scope

Prefer docs/THREAT_MODEL.md if present (from the threat-model skill): its entry points and attack classes are the focus areas, and its impact/likelihood bias which findings count as high severity — the biggest lever on false positives. No threat model → map the surface yourself first (Front 0 · Discovery).

Checklist

• Stack and package ecosystem(s) detected, attack surface mapped
• Dependency audit run for each ecosystem
• Source→sink paths traced across the four vulnerability classes
• Configuration and secret leakage scanned
• Authorization matrix produced, unprotected sensitive endpoints searched for
• Each candidate adversarially verified (N-verifier disprove pass); FALSE_POSITIVE / CANNOT_VERIFY separated out
• Severity derived from preconditions × access (not the scanner's category); verification ≠ severity
• Findings reported in severity order, no secret disclosed; ruled-out findings recorded too
• Fix options presented to the user

Fronts

Five review fronts — Discovery · Dependencies · Code (source→sink) · Configuration · Authorization: references/fronts.md (read the fronts you're scanning).

When you fan out a sub-agent per front, how you prompt it decides recall — describe vulnerability shapes not a checklist, scope each agent, and state that vulnerabilities exist: references/prompting.md.

Verify before you report

Discovery is deliberately noisy (recall-biased); a separate adversarial pass disproves each candidate before it reaches the report — the biggest lever on false positives. Run N independent verifiers per finding (each starts from the code, not the summary; each hunts for why it's wrong), classify TRUE_POSITIVE / FALSE_POSITIVE / CANNOT_VERIFY, then derive severity from preconditions × access (independently — "real" is not "critical"). The verifier procedure, the false-positive exclusion rules, the parseable verdict block, and the severity matrix live in references/verify.md. Ruled-out findings are recorded, not silently dropped.

Report

The severity scale, finding format, summary line, and the fix-presentation format live in references/reporting.md.

Invariant rules

1. Guides, does not assure — it does not replace a professional audit; say so in the report.
2. State coverage, not just findings — every report ends with a complete / partial / unknown ledger over the threat model's surfaces, each non-complete row carrying its reason. Without it, "no findings" and "never looked" read identically to whoever acts on the report (references/reporting.md).
3. Mask secrets — only the first 4 + last 4 characters (sk-p…i789); never write the full secret.
4. No automatic fix without approval — even if "Fix everything" is chosen, first show what will change.
5. Do not install tools without asking.
6. Preserve behavior — a fix must not change functionality beyond closing the vulnerability.
7. Stay local — do not send code/data to an external service, do not cross the project boundary.