The future of VRM: partnering with CVE issuers.
Small additions at CVE creation time sharpen downstream risk modeling in VRM 3.x. When CNAs add standardized exploitability hints, every consumer can differentiate risk per asset type.
Three CNA-supplied tags. Asset-aware risk.
These tags complement CVSS and EPSS. They add a low-friction exploitability shape so VRM can tell how the same CVE behaves on workstations, servers, and specialized devices.
all VRM needs from CNAs
registered in 2026
by db.gcve.eu
stronger impact foundation
How CVSS 4.0 moves the needle (and where the gap remains)
CVSS 4.0 (FIRST, November 2023) improved vulnerability scoring in four concrete ways. Several of its new features align with the problems VRM is solving. One critical gap remains: no CNA-supplied signal automatically differentiates risk per asset type.
What CVSS 4.0 improved
- Attack Requirements (AT). Captures deployment-specific conditions beyond the attacker's control.
- User Interaction expanded. None / Passive / Active (loading a page vs. opening a file).
- Supplemental metrics. Automatable, Value Density, Recovery, Safety.
- Better impact modeling. Vulnerable System + Subsequent System replaces Scope.
Detail on each improvement
- Attack Requirements: split from Attack Complexity to capture race conditions, specific configurations, and MitM positioning. All conditions beyond the attacker's control.
- User Interaction: the three values distinguish involuntary interaction (loading a page) from conscious action (opening a file).
- Supplemental metrics: Automatable (can exploitation be automated?), Value Density (richness of target resources), Recovery, and Safety (relevance to human life for OT/medical devices).
- Impact modeling: Scope replaced with a split between the Vulnerable System and Subsequent System, for more precise impact measurements.
Where the gap remains
- No per-asset scoring at the source. Environmental metrics can, but require per-CVE manual work and don't scale.
- Supplemental metrics don't affect the score. The most useful new fields are informational only.
- No operational "shape" signal. Attack Vector says how, not what kind of asset it matters on.
- Still standalone. No built-in EPSS or threat-likelihood integration.
Why each gap matters for VRM
Per-asset scoring: CVSS 4.0's Environmental metrics can produce different scores per asset, but require manual per-CVE customization by each organization. In practice, very few teams use them.
Supplemental metrics: Automatable, Value Density, and Safety are the most operationally useful new fields, and they're excluded from score calculation by design.
Shape signal: AV:Network could be a server-side RCE or a client-side drive-by. Those carry different risk profiles per asset type, and nothing in CVSS 4.0 distinguishes them on its own.
Standalone: VRM's core formula (CVSS × EPSS + context) is what bridges the likelihood gap.
CVSS 4.0 and VRM are complementary
CVSS 4.0 gives VRM a stronger impact foundation. VRM adds what CVSS 4.0's architecture doesn't deliver: CNA-supplied exploitability tags that differentiate risk per asset type without manual work, EPSS integration for likelihood, and business context modifiers from your CMDB.
The exploitability tags VRM proposes map onto CVSS 4.0's Attack Vector values and add context. AV tells you the technical access path; VRM tags tell you the operational reality: #RemoteService for network-listening services (high risk on servers, low on workstations), #LocalApplication for user-interaction exploits (high risk on workstations, low on servers), and #PhysicalAccess for proximity-based attacks (high risk on field devices, low in locked datacenters).
CNAs tag once at CVE creation. Every downstream consumer benefits, without the manual Environmental metric customization CVSS 4.0 otherwise requires.
GCVE: a decentralized alternative to CVE
The vulnerability identification landscape is evolving. The GCVE system, operated by CIRCL (Luxembourg's national CSIRT), introduces decentralized vulnerability numbering that eliminates single points of failure. VRM needs to be ready for a world where not every vulnerability has a CVE ID.
What is GCVE?
Announced April 2025, the same day the MITRE CVE funding crisis exposed single-authority fragility. By January 2026, db.gcve.eu went live, aggregating 25+ sources.
- Decentralized. 29 GNAs allocate IDs independently: CIRCL, ENISA, Red Hat, Cisco Talos, Siemens, VulnCheck, and others.
- Backward-compatible. Every CVE maps to GCVE under GNA-0 (CVE-2023-40224 → GCVE-0-2023-40224).
- No single point of failure. No single government contract. GNAs set their own policies.
What this means for VRM
- EPSS blind spots. EPSS is keyed to CVE IDs. GCVE-only findings have no EPSS score until FIRST extends their model.
- Fragmentation risk. Without unified deduplication across CVE and GCVE feeds, alert fatigue worsens.
- VRM's response. Same as any missing-data case: tool-native severity + context modifiers + internal remapping until scoring data catches up.
Vulnerabilities without CVEs
Not every security finding carries a CVE or GCVE identifier. Misconfigurations, internal application flaws, vendor-specific advisories, and emerging zero-days may lack the CVSS and EPSS data that VRM's base calculation depends on. A mature vulnerability management program needs a consistent approach for these gaps.
Why non-CVE findings score higher
Without EPSS, the multiplier that would pull a score down is absent. Non-CVE findings land at higher criticality than equivalent CVE-backed findings. This is by design: without likelihood data, err on caution.
Expect more non-CVE findings in the High and Critical tiers.
Recommended handling
- Start with tool-native severity.
- Layer Stage 1 context modifiers on top.
- Flag for internal analysis; static remapping often applies.
- Transition to full VRM scoring as data becomes available (CVE/GCVE assigned, EPSS catches up).
How these tags feed into VRM 3.0 and 3.x
VRM uses the tags as context-aware modifiers that reflect how attackers reach each asset type.
What CVE issuers can do today
CNAs can help create a consistent global language for exploitability classification with a few small steps.
- Add #LocalApplication, #RemoteService, and #PhysicalAccess tags when publishing CVEs.
- Apply multiple tags if the vulnerability can be used in different contexts (for example, a library used in browsers and servers).
- Add tag rationale to the CVE metadata or description.
- Encourage reproducible, standardized tagging across vendors.
- Help create a consistent global language for exploitability classification.
- Note: this is a small metadata addition with outsized impact. No new scoring system involved.
Roadmap for VRM 3.x
VRM continues to evolve as we partner with CNAs, vendors, and researchers.
Where we are
- Stage 0. CVSS × EPSS (base calculation).
- Stage 1. Add context modifiers from CMDB.
- Stage 2. Add age-based modifiers for healthy habits.
Where we are going
- VRM 3.x. Exploitability tag integration for per-asset-type risk scoring.
- Building on CVSS 4.0's improved impact modeling and supplemental metrics as a stronger base input.
- Preparing for GCVE and multi-namespace vulnerability identification (CVE, GCVE, vendor-specific).
- Collaborating with CNAs and GNAs to standardize tags and rationale.
- Inviting vendors and researchers to pressure-test and refine the approach.
Help us make risk modeling clearer, faster, and closer to how attackers reach real systems.
Join us in shaping VRM 3.x
CVE issuers and vendors: collaborate on exploitability tagging so every CVE ships with a consistent signal. Security leaders: subscribe for VRM 3.x updates or contact us directly.