Cvss

---
name: cvss
description: >-
  Score a vulnerability with CVSS v4.0: derive the metric vector (Base, plus
  Threat/Environmental refinement where context supports it), compute the
  exact score via the official algorithm, and explain each metric choice.
  Use whenever a finding needs a defensible severity rather than a guess.
---

# Goal

A defensible CVSS 4.0 score: the full vector string, numeric score, severity
band, and a one-line justification per metric — computed exactly, not
eyeballed or hand-calculated.

# Why not compute it by hand

CVSS 3.1's base score was a closed-form arithmetic formula reasoning could
walk through step by step. CVSS 4.0 is not: it maps the vector to one of 270
"MacroVectors" (via 6 equivalence classes) and looks up/interpolates a score
from a table defined in the official specification. Reproducing that table
from memory is exactly the kind of thing that looks plausible and is quietly
wrong. Reason through *which metric values apply* from the evidence (that
part is still judgment), then get the actual number from
`scripts/cvss4-score.py`, which wraps the `cvss` PyPI package (RedHat
Product Security's implementation of the official algorithm) rather than
reimplementing the lookup table.

# Base metrics (decide each, then state why)

Exploitability:
- **AV** Attack Vector — Network / Adjacent / Local / Physical
- **AC** Attack Complexity — Low / High
- **AT** Attack Requirements — None / Present (new in 4.0: does exploitation
  need a specific pre-existing condition — a race window, a prior
  misconfiguration already in place — beyond the attacker's own actions?)
- **PR** Privileges Required — None / Low / High
- **UI** User Interaction — None / Passive / Active

Impact — **two separate sets**, replacing 3.1's single Scope-gated C/I/A:
- **VC / VI / VA** — Confidentiality / Integrity / Availability impact on the
  **Vulnerable System** itself (the thing with the flaw).
- **SC / SI / SA** — Confidentiality / Integrity / Availability impact on a
  **Subsequent System** (anything downstream the vulnerable system can affect
  but didn't itself contain the flaw) — None / Low / High for both sets.

This is the single most important conceptual change from 3.1: there is no
`Scope` metric anymore. Where 3.1 forced a binary Unchanged/Changed judgment
call (the most-misjudged metric in that spec), 4.0 asks directly "what
happens to the vulnerable system" and "what happens beyond it" as two
independently-scored impact sets. If a flaw only affects the component that
has it, leave SC/SI/SA at None. If exploiting it lets an attacker reach data
or systems outside that component's own authority (as with the KubeHawk
agent finding — its own cluster-wide RBAC read access meant compromising it
disclosed data belonging to the whole cluster, not just the agent pod), that
belongs in VC (what the agent itself discloses) with the broader blast
radius reasoned about in the writeup even though CVSS 4.0's SC/SI/SA is
specifically about *causing* impact on a separate system, not merely *having
read access* to one — be precise about which set actually applies.

# Optional refinement metrics (only score these if the context supports it)

- **Threat (E — Exploit Maturity):** Not Defined / Unreported / Proof-of-
  Concept / Attacked. Renamed from 3.1's "Temporal" group.
- **Environmental:** `CR`/`IR`/`AR` (Confidentiality/Integrity/Availability
  Requirements for the affected asset — how much does *this* organization
  depend on it), plus Modified Base metrics (`MAV`, `MAC`, `MAT`, `MPR`,
  `MUI`, `MVC`, `MVI`, `MVA`, `MSC`, `MSI`, `MSA`) if a compensating control
  or asset-specific context changes a Base value. There is no separate
  "environmental formula" to run afterward — `cvss4-score.py` computes the
  final score from whatever combination of Base/Threat/Environmental metrics
  the vector contains in one pass.
- **Supplemental (informational only, never changes the score):** Safety,
  Automatable, Recovery, Value Density, Vulnerability Response Effort,
  Provider Urgency. Include these in the writeup when they materially affect
  how a reader should prioritize the finding, but don't expect them to move
  the number.

# Severity bands

Unchanged from 3.1: `0.0` None · `0.1–3.9` Low · `4.0–6.9` Medium ·
`7.0–8.9` High · `9.0–10.0` Critical.

# Steps

1. Reason through each Base metric from the evidence; note assumptions
   explicitly (especially for AT, and for which impact set — VC/VI/VA vs
   SC/SI/SA — actually applies).
2. Add Threat/Environmental metrics only if the engagement/report context
   actually supports them (a known exploit-maturity signal, a stated asset
   criticality, a documented compensating control) — don't invent values to
   fill out the vector.
3. Build the vector string: `CVSS:4.0/AV:_/AC:_/AT:_/PR:_/UI:_/VC:_/VI:_/VA:_/SC:_/SI:_/SA:_`
   (append any Threat/Environmental metrics after the Base block).
4. Run the script to get the exact score:
   ```
   python3 <plugin-root>/scripts/cvss4-score.py "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N"
   ```
   Requires the `cvss` package (`pip install cvss`); the script fails open
   (exit 2) rather than fabricating a score if it's missing.
5. Report the score, vector, and a one-line rationale per metric — state
   assumptions so the score can be challenged and reproduced.

# Output

```
CVSS 4.0: <score> (<Severity>)
Vector: CVSS:4.0/AV:_/AC:_/AT:_/PR:_/UI:_/VC:_/VI:_/VA:_/SC:_/SI:_/SA:_
Rationale: AV=… AC=… AT=… PR=… UI=… VC=… VI=… VA=… SC=… SI=… SA=…
```

# Notes

- Be explicit about which impact set (VC/VI/VA vs SC/SI/SA) applies to each
  consequence you describe — this replaces Scope as the metric most likely
  to be misjudged, so state the reasoning, not just the letter values.
- `security-reporting:finding`'s template references this skill for
  severity — use CVSS 4.0 there now, not 3.1.