Severity scoring
Scores a finding from separate evidence axes (impact, persistence, detectability, reachability, scope, certainty) instead of a single guess.
Sub-techniques
5
| ID | Name | Description |
|---|---|---|
V1046.001 | Impact category | Data loss, security, crash, wrong behaviour, performance, leak or maintainability. |
V1046.002 | Persistence and detectability | Transient, until restart or permanent; loud, silent or delayed. |
V1046.003 | Blast radius | One operation, one user, a subset, broad or systemic. |
V1046.004 | Certainty basis | Demonstrated by a run, traced in code, inferred from a name, or assumed. |
V1046.005 | Standard vulnerability scoring | CVSS vectors, SSVC decisions and EPSS likelihood for security findings. |
Craft it
- Have the reviewer fill each axis separately with evidence.
- Derive severity from the axes with a fixed table, never from free text.
- Cap severity when certainty is inferred or assumed.
Reverse engineer it
Signs that a codebase already runs this technique, and where to read how it is configured.
- Severity rubrics in review guidelines, or CVSS vectors in security advisories.
Open-source packages
2
- cvss (Python) RedHatProductSecurity/cvss
- CERT/CC SSVC CERTCC/SSVC