ConcertoNotes 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):
VULN-FINDINGS.jsonfrom/vuln-scan- Raw findings from
/audit --security - User-provided finding list
Optional:
THREAT_MODEL.mdfor threat scenario context.harness/engagement.mdfor 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
- Can input reach the vulnerable code? Trace the data flow from entry point to vulnerability.
- Can the attacker control the input? Distinguish between user-controlled vs. system-generated data.
- Is there a path to impact? Connecting the vulnerability to a security consequence (data leak, code exec, DoS).
- 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:
- Find pairs where finding A enables finding B (e.g., IDOR → data exposure)
- Mark chains — chained findings are more severe than individual findings
- 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