triage

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

Classification

Class	Meaning
CONFIRMED	Exploitable with demonstrated path
LIKELY	Exploitable with high confidence, minor gaps in proof
POSSIBLE	Theoretical, needs more investigation
FALSE_POSITIVE	Not exploitable with justification
ACCEPTED_RISK	Known, documented, accepted by team

Step 2: Dependency Analysis

Check if findings chain together:

1. Find pairs where finding A enables finding B (e.g., IDOR → data exposure)
2. Mark chains — chained findings are more severe than individual findings
3. Identify root causes — multiple findings from the same root cause should be grouped