Triage — Adversarial Vulnerability Validation

Triage — Adversarial Vulnerability Validation

Iron Law

A vulnerability finding is not confirmed until an adversary would agree it's exploitable. Unvalidated findings are noise.

Process

Step 0: Load Inputs

Required inputs (in order of preference):

1. VULN-FINDINGS.json from /vuln-scan
2. Raw findings from /audit --security
3. User-provided finding list

Optional:

• THREAT_MODEL.md for threat scenario context
• .harness/engagement.md for scope constraints

If no findings input exists, suggest: "Run /vuln-scan first to generate findings to triage."

Step 1: Adversarial Review

For each finding, challenge it from an attacker's perspective:

Exploitability Check

1. Can input reach the vulnerable code? Trace the data flow from entry point to vulnerability.
2. Can the attacker control the input? Distinguish between user-controlled vs. system-generated data.
3. Is there a path to impact? Connecting the vulnerability to a security consequence (data leak, code exec, DoS).
4. Are there bypasses for existing mitigations? WAF, input validation, CSP — all have bypass techniques.

Severity Validation