---
name: triage
description: Finding validation gate - 7-Question triage adapted for FIND schema. Run before moving any FIND from Research to Completed. One NO = keep in Research. All YES = move to Completed, then run /evidence.
---

# Triage: Finding Validation Gate

Use BEFORE moving any FIND from `Vulns/Research/` to `Vulns/Completed/`.

One wrong answer = keep the finding in Research. Move on to next test class.

---

## THE 7-QUESTION GATE

Ask in order. One NO = STOP for this finding.

### Q1: Can an attacker use this RIGHT NOW, step by step?
Complete this template:
```
Setup:   I need [own account / another user's ID / no account / internal access]
Request: [exact HTTP method, URL, headers, body -- copy-paste ready]
Result:  I can [read / modify / delete / execute] [exact data or action]
Impact:  The real-world consequence is [specific impact]
```
If you CANNOT write the Request line as a real reproducing command -> keep in Research.

### Q2: Is the impact within engagement scope?
- Does it affect an in-scope asset?
- Does the impact match the severity level being claimed?
- Not a third-party service the target merely uses?

### Q3: Is the root cause in an in-scope asset?
- Production asset (not staging/dev unless in scope)
- Not out-of-scope subsidiary or third-party

### Q4: Does it require privileged access that an attacker cannot realistically obtain?
- "Admin can do X" = not a finding
- "Non-admin can do X that only admin should do" = valid
- Pre-auth or low-auth is highest value

### Q5: Is this already known or documented?
- Check Vuln-index.md - not already listed?
- Check Deadends.md - not already investigated and closed?
- Not design-documented behaviour?

### Q6: Can you prove impact beyond "technically possible"?
- XSS -> show actual session theft or action execution, not just alert(1)
- SSRF -> confirm OOB callback (DNS/HTTP), not just URL echo in error message
- SQLi -> show actual data extracted from a real table
- IDOR -> show actual other-user data in response body, not just 200 status

### Q7: Not on the Never-Promote list?
Never promote to Completed without a chain:
```
Self-XSS only (no CSRF trigger)
Open redirect alone (no OAuth/ATO chain)
CORS wildcard without credentialed exfil PoC
SSRF DNS-only (no internal service access)
Rate limit without demonstrated impact
Version banner alone
Missing headers alone (no impact PoC)
```

---

## Pre-Severity Gate (run before labelling CRITICAL or HIGH)

1. Have you validated the FULL chain to attacker-attainable impact, or only one primitive?
2. What does the attacker walk away with in one concrete sentence?
3. Have you reproduced the full chain end-to-end at least twice?
4. Is there a validation step (signature check, audience check, MFA) still gating the chain?

A "primitive confirmed" != exploitable. Downgrade until the gate is bypassed.

---

## Decision

| Result | Action |
|--------|--------|
| All 7 YES + Pre-Severity Gate clean | Move FIND to Vulns/Completed/. Update status in Vuln-index.md. Run `python3 scripts/find-lint.py` and fix any gaps (Description/PoC/Impact/Remediation + CVSS for HIGH/CRITICAL) so it is report-ready. Then run /evidence. |
| Any NO | Keep in Vulns/Research/. Update status to PARTIAL (reason) in Vuln-index.md. Document what is missing. |
| Q7 chain required | Move to Vulns/Research/ with note "chain required: [what is needed]". |