security-auditor

Security Auditor

Overview

This skill performs a rigorous, evidence-based security audit of a codebase against the OWASP Top 10 (2021). Every finding must be concrete and exploitable, not a vague "consider validating input." A finding is only worth reporting if you can name the vulnerable file and line, describe how an attacker triggers it, rate its severity, and supply a working fix.

Keywords: security audit, OWASP Top 10, SQL injection, XSS, SSRF, IDOR, broken access control, authentication, secrets, cryptography, deserialization, command injection, path traversal, CSRF, vulnerability, CWE, CVSS, penetration test, threat model, secure code review.

The deliverable is a prioritized findings report (use templates/finding-report.md) where each item follows: vulnerability → location → exploit → impact → fix.

Workflow

1. Scope the audit. Identify language(s), framework(s), entry points (HTTP routes, message handlers, CLI args, file uploads), trust boundaries, and where untrusted input enters. Note authn/authz mechanism and the data store(s).
2. Run the grep triage. Execute scripts/grep_audit.sh <path> to surface high-signal patterns (raw SQL string building, eval, pickle.loads, dangerouslySetInnerHTML, hardcoded secrets, weak crypto, disabled TLS verification). Triage is a lead generator, not proof — every hit must be manually confirmed.
3. Trace tainted data. For each candidate, follow untrusted input from source (request param, header, body, file) to sink (DB query, shell, file path, HTML, deserializer, redirect). A vulnerability exists only when a source reaches a dangerous sink without adequate sanitization for that sink.
4. Walk the OWASP checklist. Go through references/owasp-top-10.md category by category. For each, decide: Not Applicable / No Issue Found / Finding. Do not skip categories — absence of evidence is itself worth noting.
5. Confirm exploitability. For each finding write a concrete proof-of-concept: the exact request, payload, or call sequence. If you cannot construct a PoC, downgrade to "potential" and say why.
6. Rate severity. Use the CVSS-lite rubric in references/severity-rubric.md (Critical / High / Medium / Low / Info) based on impact × exploitability × exposure.
7. Write the fix. Provide minimal, idiomatic, copy-pasteable remediation — parameterized query, output encoding, allowlist, framework auth guard. Prefer fixing the root cause, not the symptom.
8. Assemble the report. Sort findings by severity. Use templates/finding-report.md. Include a one-line executive summary and a coverage table showing which OWASP categories you reviewed.