triagelisted

# 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 | Criteria | Adjust | |----------|--------| | Requires authentication | Lower by 1 level | | Requires specific permissions | Lower by 1 level | | Chained with another finding | Raise by 1 level | | Affects all users | Raise by 1 level | | No mitigation in place | Raise by 1 level | | Defense-in-depth exists | Lower by 1 level | ###