security-audit

Security Audit

Run a defensive, read-only security sweep over ${input.path}. This skill is for authorized auditing of code you own or are permitted to test. Never use it to evade detection or attack third-party systems.

Procedure

1. Detect available scanners. Probe PATH (where <tool> on Windows, which <tool> elsewhere) for each candidate. If ${input.tools} is set, restrict to that subset. Skip any tool that is not installed — note it in the summary rather than failing.
2. Pick scanners by content. Run only what fits the target:
   • Python present → bandit -r "${input.path}" -f json (SAST) and, for dependency files, pip-audit -r <requirements file> or pip-audit in a project dir.
   • JS/TS present → npx eslint "${input.path}" -f json if an eslint config exists.
   • Any language → semgrep --config auto --json "${input.path}" when semgrep is installed (falls back to --config p/ci offline).
   • Secrets → gitleaks detect --source "${input.path}" --report-format json (or trufflehog filesystem) to catch committed credentials/keys.
   • Always run ruff check "${input.path}" --output-format json when Python is present — its security-adjacent lint rules (S-prefixed) are cheap signal.
3. Run each scanner via chat_agent_executer. Capture stdout even on a non-zero exit code — most of these tools exit non-zero precisely because they found issues. Truncate any single tool's raw output to ~16000 chars before parsing.
4. Normalise findings into one shape: {tool, file, line, severity, rule_id, message}. Map each tool's native severity onto critical | high | medium | low. Treat any committed secret/credential as critical.
5. Filter & count. Drop findings below ${input.min_severity}. Produce severity_counts = {critical, high, medium, low}.
6. Summarise for action. Lead with the count of critical/high issues, name the top 3 things to fix first, and list which scanners were unavailable so the reader knows the coverage gaps.