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

Step 3: Produce Output

Write TRIAGE.json:

{
  "triage_date": "ISO-8601",
  "source": "VULN-FINDINGS.json | audit | manual",
  "findings": [
    {
      "id": "V1",
      "classification": "CONFIRMED | LIKELY | POSSIBLE | FALSE_POSITIVE | ACCEPTED_RISK",
      "original_severity": "CRITICAL",
      "adjusted_severity": "HIGH",
      "severity_adjustments": ["requires auth (-1)", "no mitigation (+1)"],
      "exploit_path": ["entry point → vulnerable function → impact"],
      "chains_with": ["V3"],
      "root_cause_group": "RC1",
      "remediation": "specific fix instruction",
      "effort": "low | medium | high",
      "validation_notes": "why this classification was chosen"
    }
  ],
  "root_cause_groups": [
    {
      "id": "RC1",
      "description": "shared root cause",
      "findings": ["V1", "V2"],
      "fix_once": "single fix that resolves all findings in group"
    }
  ],
  "chains": [
    {
      "findings": ["V1", "V3"],
      "combined_severity": "CRITICAL",
      "description": "V1 enables V3, creating..."
    }
  ],
  "summary": {
    "total_input": 10,
    "confirmed": 3,
    "likely": 2,
    "possible": 1,
    "false_positive": 2,
    "accepted_risk": 2,
    "root_cause_groups": 3,
    "chains": 1
  },
  "action_items": [
    {
      "priority": 1,
      "severity": "CRITICAL",
      "finding_ids": ["V1"],
      "action": "specific remediation step",
      "effort": "low"
    }
  ]
}

Step 4: Report

Present prioritized remediation plan:

## Triage Report

### Summary
- Input: N findings
- Confirmed: X | Likely: Y | False positives: Z
- Root cause groups: K (fix-once opportunities)
- Chained findings: C

### Priority Actions
1. [CRITICAL] V1: {description} — {effort} effort
   Fix: {remediation}
2. [HIGH] V2+V3 (chain): {description} — {effort} effort
   Fix: {remediation}

### Accepted Risks
- V7: {description} — {justification}

### Suggested Next Steps
- Fix priority 1-3 before merge
- Run `/vuln-scan` after fixes to verify

Anti-Rationalization

| Excuse | Rebuttal | What to do instead |

|--------|----------|-------------------|

| "All findings are real, no need to triage" | False positives waste fix time and erode trust in the process. | Validate every finding. Noise reduces signal. |

| "Triaging takes too long" | Fixing false positives takes longer than triaging them. | Triage first, fix only confirmed findings. |

| "It's obviously a vulnerability" | "Obvious" vulnerabilities are often mitigated by context you haven't checked. | Trace the exploit path before confirming. |

| "We can just fix them all" | Not all findings need fixing. Some are accepted risks. | Prioritize by confirmed severity and effort. |

| "Chaining is theoretical" | Real-world breaches use chained vulnerabilities. | Check for chains — they change severity. |

Evidence Required

• [ ] Every finding classified (CONFIRMED/LIKELY/POSSIBLE/FALSE_POSITIVE/ACCEPTED_RISK)
• [ ] Each CONFIRMED finding has a traced exploit path
• [ ] Each FALSE_POSITIVE has justification for dismissal
• [ ] Severity adjustments documented per finding
• [ ] Root cause groups identified where applicable
• [ ] Chained findings identified and combined severity assessed
• [ ] TRIAGE.json written with action items
• [ ] Priority actions ordered by severity × effort

Red Flags

• All findings marked CONFIRMED without exploit paths
• All findings marked FALSE_POSITIVE without justification
• No severity adjustments — original severity is almost never perfect
• Ignoring finding chains — individual severity ≠ chain severity
• Skipping dependency analysis between findings
• TRIAGE.json action items not ordered by priority