VRM
VRM 4.0 Draft vulnerabilityriskmodel.com
Public draft · request for comment

Stop freezing scores. Re-derive the decision.

In 2026 the ground under VRM 3.x shifted: the NVD stopped refereeing CVSS scores, and CISA made SSVC-style decisions the federal standard. VRM 4.0 keeps the 3.x spine — impact × likelihood, plus business context — but sorts every input by how fast it changes and re-derives the volatile parts from live sources at decision time. The score becomes a byproduct of a continuously recomputed decision, not a frozen label.

Criticality = Impact × Likelihood × AssetShape + Context

Impact anchors on SSVC Technical Impact, Likelihood is the worst exploitation signal across every source you trust, AssetShape is the per-asset-type dimension SSVC lacks, and Context is unchanged from VRM 3.x. This is a working draft — the open questions are published below, and VRM 3.0 remains the current released model.

Apr 15 — NVD stops normalizing CVSS Jun 10 — BOD 26-04 makes SSVC-style triage federal Jun 17 — SSVC lands in the NVD feeds
263%
CVE volume growth
2020 → 2025
10,000+
2025 CVEs with
no CVSS score at all
~50%
of CVEs carry a
CISA SSVC record
16
rows in BOD 26-04's
decision table
Why 4.0

Three dates in 2026 broke the frozen-score model.

VRM 3.x is built on Criticality = Base × Risk + Context, where Base is a CVSS number. Within one quarter, that foundation cracked from two directions at once: the referee left the field, and the federal government switched games.

April 15, 2026 NIST / NVD

The NVD stops normalizing CVSS

NIST moved the NVD to risk-based enrichment: it now enriches only CVEs that are in KEV, affect federal-government software, or qualify as "critical software" under EO 14028. It no longer recalculates a CVSS score when the CNA already supplied one, and the pre-March-2026 backlog moved to "Not Scheduled."

What it means for VRM: for most new CVEs, "Base" is now a CNA self-reported CVSS with no independent QC — and vendors have a standing incentive to score their own bugs low. Roughly a third of 2025 CVEs were ever fully enriched.

June 10, 2026 CISA

BOD 26-04 makes SSVC-style triage the federal standard

BOD 26-04, "Prioritizing Security Updates Based on Risk," orders federal civilian agencies to prioritize by a four-factor decision model — Asset Exposure, KEV status, Automatable, Technical Impact — and revokes the CVSS-era directives (BOD 19-02, BOD 22-01). A 16-row table maps each combination to a remediation deadline, from days for the highest-risk combinations down to "defer to the next scheduled upgrade."

What it means for VRM: KEV became the most widely adopted prioritization signal on earth despite only ever binding federal agencies. The four-factor model is on the same trajectory — auditors, insurers, and frameworks will follow. VRM 4.0 should be ahead of that adoption.

June 17, 2026 NVD + CISA

SSVC becomes a first-class metric in the NVD feeds

The NVD API and data feeds now carry CISA-ADP SSVC decision points alongside CVSS, across roughly 95% of records. SSVC is no longer something you fetch from a side repo — it's in the pipe VRM already drinks from.

What it means for VRM: the structured inputs 4.0 needs (Technical Impact, Automatable, Exploitation) arrive in the same feed that used to deliver the refereed CVSS number. The plumbing argument for staying CVSS-only is gone.

The backdrop. CVE volume grew 263% from 2020–2025, FIRST forecasts ~50,000 additional CVEs in 2026, and AI-assisted discovery is compressing the disclosure→weaponization window. A model whose base input is a hand-curated number that arrives late — or never — cannot survive that environment.
The trap

Don't just swap CVSS for the CISA SSVC decision.

The naive 4.0 would consume CISA's published SSVC decision in place of CVSS. That imports three failure modes, and the third one matters most.

1. It's still point-in-time

A CISA SSVC record is a snapshot at assessment time. We've documented CVEs assessed once at publication (Exploitation: None → Attend) and never re-touched — even after the CVE record and EPSS both refreshed months later. If a PoC drops tomorrow, that record won't tell you.

2. Coverage is partial

CISA Vulnrichment carries SSVC for roughly half of CVEs. A model that assumes an authoritative SSVC record exists for every finding is blind on a large fraction of the corpus — an enterprise needs a generation or fallback path for the uncovered half.

3. The decisions lag reality

Documented side-by-side: CISA-ADP reads Exploitation: POC while an independent source reads Exploitation: ACTIVE for the same CVE. Exploitation evidence is frequently available elsewhere days to years before it appears in KEV.

Conclusion. SSVC's structure — decision points plus a decision — is a genuine improvement over a single severity number. But SSVC's published instance cannot be trusted as current or complete. VRM 4.0 treats any single SSVC record as one lagging input among several, never as ground truth.
The central design move

Sort every input by how fast it changes.

The staleness problem is a data-sourcing problem, not a model problem. Every signal VRM uses changes at a different rate. VRM 3.x froze them all together into one score. VRM 4.0 classifies each input by volatility, binds it to the freshest authoritative source, and only ever freezes the parts that are genuinely stable.

T0 · Volatile Never cached — evaluated at query time

Changes hourly or daily. Can flip a decision overnight.

  • Inputs: exploitation status, asset exposure.
  • Sources: KEV (live lookup), EPSS (daily), exploit-tooling presence (Metasploit, Nuclei), your EASM / attack-surface data.
  • Discipline: this is the axis that flips Attend → Act. It is never read from a stored score.
T1 · Slow Re-pull when the CVE record changes

Changes occasionally, on new evidence.

  • Inputs: Technical Impact, Automatable, CWE.
  • Sources: CISA-ADP SSVC, VulnCheck SSVC, CNA data.
  • Discipline: point-in-time is acceptable here. Re-pull only when the CVE record's Last-Modified changes.
T2 · Static Recompute on CMDB change events

Changes only on business or architecture events.

  • Inputs: data sensitivity (PHI/PII), system criticality, OS lifecycle, asset class.
  • Sources: CMDB, data-classification, and lifecycle tooling.
  • Discipline: compute once; recompute when the CMDB says something changed.
This is exactly how BOD 26-04 behaves — and not by coincidence. It reads Technical Impact and Automatable from the frozen Vulnrichment record (T1), but re-checks the live KEV catalog and your live exposure at decision time (T0), and its deadlines move as those signals move. VRM 4.0 generalizes that discipline to every input, and to the score itself. When a vulnerability goes from unexploited to actively exploited, nobody re-scores anything by hand: the T0 lookup returns a new value, the composite recomputes, the criticality rises, and the SLA clock accelerates — automatically.
The model

VRM 4.0: same spine, robust inputs.

VRM 4.0 preserves the VRM 3.x spine — impact × likelihood, then modifiers — so the six criticality tiers and the time-weighted SLA clock carry over unchanged. What changes: the two fragile inputs (a raw CVSS number, a raw EPSS number) are replaced by composites drawn from the volatility-tiered sources above.

Core equation
Criticality = Impact × Likelihood × AssetShape + Context
  • Impact: SSVC Technical Impact anchor; CVSS refines it only where independently reliable.
  • Likelihood: exploitation composite — max(KEV, active intel, EPSS, PoC ∧ Automatable, exploit tooling).
  • AssetShape: VRM exploitability tag × asset-class reachability multiplier — the piece SSVC lacks.
  • Context: the VRM 3.x business modifiers, unchanged (PHI/PII, criticality, EOL, density, age).

Impact: a binary that can't be lowballed

Map SSVC Technical Impact onto VRM's existing 0–10 impact axis: Total (adversary gains total control) anchors high (≈ 9–10); Partial (some control, disclosure, DoS) anchors mid (≈ 5–6). Where a genuinely independent CVSS exists — a reputable non-vendor CNA, or your own analyst re-score — use it to refine within the band.

Why this is more robust, not less: the CNA-lowball problem attacks a precise number. A partial/total judgment is far harder to shade downward and survives the loss of the NVD's QC layer. You trade granularity for integrity — the right trade after April 2026.

Likelihood: the worst signal wins

VRM 3.x used raw EPSS as the Risk multiplier. In 4.0, Likelihood is the most urgent exploitation signal across all available sources:

  • In KEV (CISA or VulnCheck) → pin near 1.0. Confirmed exploitation dominates everything.
  • Active-exploitation intel from any trusted source, even absent KEV → near 1.0.
  • Public PoC ∧ Automatable → high. Commoditized exploitation is imminent.
  • Exploit tooling present (Metasploit module, Nuclei template) → high; ground-truth automatability.
  • EPSS supplies the continuous background probability when none of the above fire.

Taking the max means you are never worse off than the single most current feed. If CISA still says POC but your telemetry says active, VRM uses active. You stop betting on any one authority being up to date.

AssetShape: the dimension SSVC doesn't have

SSVC has no asset dimension: a #RemoteService RCE and a #LocalApplication RCE produce the same SSVC decision, yet they are not the same risk on a given box. The three exploitability tags supply exactly that missing axis, and they modify Likelihood — asset shape is really about whether the exploit path is reachable on this asset class.

A Chrome RCE is severe on a laptop and near-irrelevant on a hardened backend; an unauthenticated web RCE is critical on a server and meaningless on a workstation; a USB takeover is negligible in a locked datacenter and severe on a patient-facing device. The same SSVC decision produces different VRM criticality per asset type — automatically. See the full tag × asset-class matrix.

Context: unchanged from 3.x

The additive context modifiers stay exactly as they are: PHI/PII presence, system criticality and dependencies, EOL OS, vulnerability density, and age. They operate on impact and urgency, they already sit at tier T2 (static, CMDB-sourced), and they keep rewarding the hygiene habits VRM is designed to incentivize.

Why the spine is preserved on purpose: keeping impact × likelihood + context means the entire 3.x downstream apparatus survives — the six tiers, the dynamic SLA clock, remapping, the non-CVE fallback. Adoption is a change of inputs, not a rewrite. Existing 3.x implementers migrate incrementally.

Reconciliation

Poly-source by design. No single point of failure.

VRM 3.x implicitly assumed a single authoritative source — the NVD — for its base inputs. That assumption is dead. VRM 4.0 defines how multiple sources reconcile.

Reconciliation rules

  • Exploitation / Likelihood: take the max-urgency value across CISA KEV, VulnCheck KEV, active-exploitation intel, EPSS, and exploit-tooling presence.
  • Technical Impact / Automatable: prefer the originating CNA where credible; otherwise CISA-ADP or VulnCheck SSVC. On disagreement, take the more severe and flag for analyst review.
  • Identifier-agnostic: accept CVE, GCVE, vendor advisories, and no-ID findings. GCVE-only findings fall to the non-CVE path until likelihood data exists.

Evidence-centric, not score-centric

Provenance is recorded. Every decision carries which source supplied which value, and when. The output is a decision plus an audit trail — defensible to leadership, auditors, and insurers.

And because CISA covers only about half of CVEs, a large enterprise needs an internal SSVC generation capability — or a commercial feed that provides one — for the uncovered half. 4.0 does not depend on CISA having gotten there first.

Decision → number

SSVC outputs a decision. VRM needs a number. Here's the bridge.

SSVC deliberately outputs a decision — Track, Track*, Attend, Act — not a score. VRM needs a number for its six tiers and its time-weighted SLA clock. This is the central design decision for the group to ratify.

(a) Decision-native

Adopt Track / Track* / Attend / Act directly and map each to an SLA band, matching BOD 26-04's structure exactly. Cleanest federal alignment — but it loses VRM's continuous score, the fine-grained time-weighted clock, and the two "above Critical" tiers VRM invented.

(b) Composite-numeric Recommended

Keep the numeric criticality and derive it from the same decision points, so VRM produces both a number (for the clock, dashboards, and the upper tiers) and a decision label (for 26-04 alignment). The number is computed continuously from T0/T1/T2 inputs; the label is a function of the number's tier. Everything VRM 3.x does is preserved, plus SSVC's structure and federal defensibility.

The BOD 26-04 crosswalk

The single biggest adoption argument to a board: "this aligns us with the federal risk-based directive." Every 26-04 factor has a home in VRM 4.0 — and 4.0 is a superset, adding asset-type shape, business context, age pressure, and a continuous score, none of which 26-04 has.

BOD 26-04 factor VRM 4.0 home Volatility tier
Asset Exposure AssetShape + Context exposure modifier T0
KEV status Likelihood composite (KEV pins near 1.0) T0
Automatable Likelihood composite (PoC ∧ Automatable, tooling) T1 / T0
Technical Impact Impact core T1

Note: secondary sources disagree on the exact day-count tiers in 26-04's remediation table. Verify against Table 1 of the directive itself before hard-coding deadlines.

Demotions

What VRM 4.0 drops or demotes.

  • CVSS as Base: demoted from "the base" to one optional impact signal, used only where independently reliable. Not removed — reputable CNAs and analyst re-scores still produce useful CVSS — but no longer load-bearing.
  • NVD as single source of truth: removed. The NVD is one feed among several; it no longer normalizes CVSS and covers only a prioritized slice.
  • Trusting any single SSVC record: removed. Superseded by the max-urgency reconciliation rule and T0 live evaluation.
  • Static scores generally: the frozen-number model is the thing 4.0 exists to kill. Only T2 inputs are cached.
Try it

Feel the model move.

Toggle a signal and watch the decision re-derive — there is no "calculate" button because there is no frozen score. The default scenario is an unauthenticated #RemoteService RCE on a server: flip the KEV switch and watch a tracked finding become an emergency.

Provisional values. The anchors and multipliers in this demo are draft defaults for illustration only — the exact Technical-Impact anchors and AssetShape magnitudes are open questions the VMRG has not ratified. For the released model, use the VRM 3.0 calculator.
T1 · Impact changes rarely — re-pull on CVE record updates
T0 · Likelihood never cached — the worst signal wins
EPSS 0%background probability when nothing above fires100%
EPSS: 5%
T0 / T2 · AssetShape the dimension SSVC lacks
T2 · Context unchanged from VRM 3.x — recompute on CMDB events
Output re-derived on every change — nothing frozen
Derivation & provenance
Impact
Likelihood (winning signal)
AssetShape
Impact × Likelihood × AssetShape
Context
VRM 4.0 draft criticality
Request for comment

Open questions for the VMRG.

These are the decisions the draft leaves to the group. They are tuning and scoping decisions, not architectural ones — but "4.0-compliant" should mean something, so they need answers before the draft is ratified.

  1. Numeric mapping. Ratify composite-numeric vs. decision-native, then set the Technical-Impact anchors and AssetShape magnitudes.
  2. Internal SSVC generation. Does the group publish a reference method for generating SSVC decision points for the ~half of CVEs CISA doesn't cover, or does 4.0 recommend a commercial feed and stay implementation-neutral?
  3. Exploitation source list. Which feeds are in the canonical max()? Is exploit-tooling presence (Metasploit, Nuclei) a first-class signal, and how are proprietary intel feeds handled for implementation-neutrality?
  4. Asset shape without a CMDB. T0 exposure and asset class are the inputs most organizations lack cleanly. Graceful-degradation default when asset class is unknown: probably assume worst-case shape, consistent with VRM's err-toward-caution principle.
  5. Tag adoption reality. The exploitability tags depend on CNAs tagging at creation. Given CNAs already under-supply CVSS and CWE, is CNA tagging realistic, or does 4.0 assume VRM-side tag inference from CWE, Attack Vector, and exploit descriptions?
  6. Cadence commitment. Define the T0 refresh SLA (e.g., re-evaluate exploitation daily and on any KEV/EPSS change) as a normative part of the spec, so "VRM 4.0-compliant" means the volatile inputs are live.

This draft gets better with your objections.

Practitioners, CNAs, feed vendors, and researchers: tell us where this breaks in your environment. Which sources belong in the max()? What should the anchors be? Where does the migration path fall apart?

Comment on the draft Every piece of feedback is read. The open questions above get resolved in public, and the draft is revised until the group ratifies it.
Migration

From 3.x to 4.0, one independently shippable stage at a time.

Same "start where you are" philosophy as VRM 3.x: each stage improves prioritization on partial data, and none requires the next.

Stage 0 Swap the likelihood source

Keep Base × Risk; source Risk from the exploitation composite

Replace raw EPSS with max(KEV, active intel, EPSS, PoC ∧ Automatable, tooling). Immediate robustness against CISA lag, zero new data requirements.

Stage 1 Swap the impact source

Replace the CVSS Base with the SSVC Technical Impact anchor

Keep CVSS as a refinement where reliable. Now resilient to CNA-lowballed and missing CVSS.

Stage 2 Add shape

Turn on AssetShape multipliers

For the asset classes you can identify. Per-asset-type scoring goes live.

Stage 3 Go live

Enforce the T0 refresh discipline

Publish provenance and the 26-04 crosswalk. VRM is now a continuously recomputed decision, not a score.