Evidence Standard
The nine links a verified vulnerability should establish: attacker control, reachability, boundary failure, safe reproduction, impact, preconditions, root cause, fix, and regression proof.
The nine links
A verified vulnerability should establish all of the following, where applicable. The list is the acceptance criterion for promoting a candidate into a finding.
- 1. Attacker control
- What input or state can the attacker influence?
- 2. Reachability
- How does that influence reach the vulnerable path?
- 3. Boundary failure
- Which intended control fails, and where is it supposed to be enforced?
- 4. Safe reproduction
- A local or staging proof, or bounded production-safe evidence.
- 5. Impact
- Concrete confidentiality, integrity, availability, or business effect.
- 6. Preconditions
- The roles, state, timing, and configuration the exploit requires.
- 7. Root cause
- The defective invariant, not only the symptom.
- 8. Fix
- Preferably at the canonical boundary.
- 9. Regression
- A test that fails against the vulnerable control and passes after the fix.
The evidence record
schemas/evidence-v1.schema.json gives every piece of evidence an identity so a finding can cite it rather than paraphrase it. Required fields are the schema version, an evidence ID, a kind, a status, a source, a summary, the environment, artifacts, and redactions.
Optional fields carry details, a location, and the related hypothesis IDs. The redaction field is required rather than optional because evidence routinely contains material that must not be copied into a report.
- Evidence distinguishes direct observation from inference. A trace and a hypothesis about a trace are different records.
- Dynamic proof stays inside the recorded authorized execution mode.
- Artifacts are referenced with a digest, so a later reader can tell whether the artifact changed.
- Tool severity is retained only as an untrusted signal, never as the SecHelix severity.
Severity without proof
Severity combines impact, exploitability, prerequisites, scope, and recoverability. A CWE category that is sometimes Critical does not make this instance Critical.
| Severity | Release meaning |
|---|---|
| Critical | Direct compromise of a core trust boundary with severe impact. |
| High | Serious integrity, confidentiality, or financial isolation failure. |
| Medium | Meaningful but constrained weakness. |
| Low | Narrow hardening defect with limited impact. |
| Info | Design or observability improvement, not a vulnerability. |
Severity without proof should be conservative. That rule is in the skill, not just in the guidance.
Confidence states
Confidence is separate from severity, and separate again from the applicability label. A single finding carries all three.
- VERIFIED
- The evidence chain is complete enough to act on.
- LIKELY_BUT_UNPROVEN
- An important signal that is missing a decisive link.
- FALSE_POSITIVE
- The suspected path is blocked, or the assumptions are wrong.
- DUPLICATE_ROOT_CAUSE
- Another verified issue already explains the same failure.
- BLOCKED_BY_ENVIRONMENT
- Proof requires legitimate environment evidence that is unavailable.
A worked chain
The published case study establishes seven links for a missing security header policy: the attacker owns the embedding page, every public route was served without a framing policy, no frame-ancestors and no X-Frame-Options were present, a local probe page on a separate origin rendered the whole interface, the realistic impact was UI redress rather than account takeover, the precondition was a victim visiting the attacker page, and the root cause was that the application never declared a header policy at all.
The honest severity there is Medium, because the application performs no authenticated state-changing actions. That downgrade is the evidence standard working.