triage

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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`:

```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"
    }
  ]
}
```

From epicsagas/epic-harness, Apache-2.0.

More from epicsagas/epic-harness