# ADR-0003: Severity tiers locked to upstream `deepsec`, not invented

## Status
Accepted

## Date
2026-05-06

## Context

The standard emits findings with explicit severity. Three options were on the table when the run-report format was being designed:

1. Invent a new tier set tuned to the standard's defensive-evidence frame (e.g., `BLOCKING` / `MATERIAL` / `INFO`).
2. Adopt FIRST CVSS v4.0 numerical scoring (already in the standards spine).
3. Adopt the upstream `vercel-labs/deepsec` scanner's existing tier strings verbatim.

Inventing a new tier set would have been justified if the existing options had structural gaps. Reviewing `deepsec`'s output revealed they don't: the upstream scanner emits `CRITICAL / HIGH / MEDIUM / HIGH_BUG / BUG` with triage tags `P0 / P1 / P2 / skip`. These are well-formed, distinguish between security severity (`HIGH`) and bug severity (`HIGH_BUG`), and ship with the scanner.

Inventing a parallel tier set would force adopters to translate between the standard's vocabulary and the scanner's output every time a finding moves between systems. Silent translation churn, exactly what Rule 4 (Standards as vocabulary, not ceremony) is supposed to prevent.

CVSS v4.0 is appropriate for severity *expression* on individual findings but is too granular for run-level triage. Adopters need a small ordinal set for "what do I do with this finding tomorrow morning."

## Decision

Lock the standard's severity tiers to upstream `deepsec` verbatim:

- **CRITICAL:** exploitable, high blast radius, defensive evidence strong
- **HIGH:** exploitable, defensive evidence strong
- **MEDIUM:** likely-exploitable, defensive evidence partial
- **HIGH_BUG:** confirmed bug with security implications, exploitability unclear
- **BUG:** confirmed bug, security implications uncertain or low

Triage tags: `P0` / `P1` / `P2` / `skip` (also from `deepsec`).

CVSS v4.0 remains in the standards spine for severity *expression* on individual finding packets when adopters need a numerical score.

## Alternatives Considered

### Invent the tier set
- Pros: Maximum semantic fit to the standard's defensive-evidence frame.
- Cons: Translation churn for every adopter; upstream scanner output would have to be mapped on the way in and out of the standard's run reports.
- Rejected: violates Rule 4 (standards as vocabulary) and adds friction without offsetting clarity gain.

### Use CVSS v4.0 alone
- Pros: Industry standard; numerical comparability.
- Cons: Too granular for run-level triage; reviewers don't action a "7.4" the same way they action a "HIGH".
- Rejected: CVSS is for expression, not triage.

### Use OWASP risk-rating methodology (Likelihood × Impact)
- Pros: Defensible-in-audit framework.
- Cons: Requires manual scoring per finding; doesn't survive being machine-emitted by the scanner.
- Rejected: too heavy for the run-level decision.

## Consequences

- Adopters cite `deepsec` findings using the same vocabulary the scanner emits. Zero translation.
- The run report format in `standard.md` and the run-closeout template both use these strings verbatim.
- If `deepsec` upstream changes its tiers (e.g., adds `LOW`), the standard tracks the upstream change in a minor version bump rather than diverging.
- Adopters running the standard *without* `deepsec` (e.g., applied to a non-software business case like the stablecoin specimen) still use the same tiers. `HIGH / P1` reads identically across software and policy domains, which is the whole point of using upstream vocabulary.
- CVSS v4.0 stays in the spine as the numerical-expression layer when needed; tiers are the triage layer.

## Reference

- Upstream `deepsec` source: <https://github.com/vercel-labs/deepsec>
- Severity-tier mapping in the standard: `standard.md` → "Severity tiers (use deepsec's, do not invent)" section