security-audit

Security Audit Workflow

A stateful adversarial audit. Discovery is deterministic (clawness scan), judgment accumulates in a ledger (.clawness/security/findings.json), so runs converge instead of repeating.

Before spawning agents: the red/blue-team pass launches several adversarial sub-agents and is token-intensive. If you surfaced this proactively (the user mentioned security but didn't explicitly ask to run it), first ask: "Want me to run the full red team / blue team audit now?" and proceed only once they confirm. Running clawness scan itself is cheap and deterministic — you may run that first to show the surface, then ask before fanning out agents. If the user explicitly invoked /clawness:security-audit or already said yes, skip the question.

The CLI isn't on PATH — reach it through the stashed wrapper:

CLAW="${CLAUDE_CONFIG_DIR:-$HOME/.claude}/clawness/clawness-cli.sh"
bash "$CLAW" scan --project .          # enumerate + accumulate the ledger
bash "$CLAW" scan status --project .   # show coverage without re-scanning

If $CLAW doesn't exist, the bootstrap hasn't run yet — start a fresh session.

Steps

1. Enumerate (deterministic, free) — Run bash "$CLAW" scan --project <scope>. This lists sink/source candidates (SQL/command injection, unsafe deserialization, XSS, path traversal, broken authz, hardcoded secrets, weak crypto, SSRF), each with a CWE, a mapped rule id, and a stable id, and merges them into the ledger. Note the coverage line it prints. Use --new-only to see just what hasn't been adjudicated yet, --class <name> to focus one category.

2. Scope — If the user named a module or directory, pass it as --project and focus there. Otherwise let the scan cover the tree and prioritise the security-sensitive candidates (auth, authorization, data validation, endpoints, queries, secret handling).

3. Red Team — adjudicate only what's NEW. Delegate to the security-red-team sub-agent, handing it the candidates whose ledger status is new (from scan --new-only): "Adjudicate these enumerated candidates. For each, decide confirmed / false-positive and give the attack path and file:line. Check for current-month CVEs affecting our stack. Also look for classes the enumerator can't see (logic flaws, auth bypass, IDOR beyond the heuristic). Do NOT re-litigate items already marked confirmed/false-positive/fixed." Have it write each verdict back to the ledger.