| 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)
- Have you validated the FULL chain to attacker-attainable impact, or only one primitive?
- What does the attacker walk away with in one concrete sentence?
- Have you reproduced the full chain end-to-end at least twice?
- 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]". |
