The Future of VRM: Partnering with CVE Issuers

Exploitability insight at the source

CVE issuers have the earliest, clearest understanding of how a vulnerability is reached. Capturing that shape at publication gives defenders a durable signal that travels with the CVE.

• Zero friction for VRM adopters: the hint is already in the CVE.
• Complements CVSS and EPSS instead of competing with them.
• Creates consistent language for downstream tooling.

Better prioritization per asset

With exploitability shape, the same CVE scores differently on a workstation, a hardened backend server, or a field-deployed device. VRM 3.x can elevate the risks that match each asset’s reality while de-emphasizing those that do not.

• Workstations vs. servers vs. appliances are treated uniquely.
• Noise drops and remediation queues focus on what matters.
• Models stay simple while adding meaningful nuance.

What CVSS 4.0 improved

• Attack Requirements (AT): A new metric split from Attack Complexity that captures deployment-specific conditions (race conditions, specific configurations, MitM positioning) beyond the attacker's control.
• User Interaction expanded: Now has three values (None, Passive, Active) instead of two, better capturing the difference between involuntary interaction (loading a page) and conscious action (opening a file).
• Supplemental metrics: New informational fields including Automatable (can exploitation be automated?), Value Density (richness of target resources), Recovery (system recoverability), and Safety (relevance to human life for OT/medical devices).
• Better impact modeling: Scope was replaced with Vulnerable System and Subsequent System impact splits, giving more precise impact measurements.

Where the gap remains

• No per-asset-type scoring at the source. 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 because it does not scale.
• Supplemental metrics do not affect the score. The most operationally useful new fields (Automatable, Value Density, Safety) are informational only and excluded from score calculation.
• No operational "shape" signal. CVSS 4.0's Attack Vector (Network/Adjacent/Local/Physical) describes how a vulnerability is exploited, but not what kind of asset it matters on. AV:Network could be a server-side RCE or a client-side drive-by; those have very different risk profiles per asset type.
• Still standalone. CVSS 4.0 has no built-in mechanism to incorporate threat likelihood data like EPSS. VRM's core formula (CVSS x EPSS + context) bridges that gap.

What is GCVE?

GCVE was publicly announced in April 2025, the same day the MITRE CVE funding crisis revealed how fragile a single-authority model can be. By January 2026, db.gcve.eu went live, aggregating data from 25+ sources.

• Decentralized numbering. GCVE Numbering Authorities (GNAs) allocate IDs independently, without waiting for a central authority. 29 GNAs are registered, including CIRCL, ENISA (EUVD), Red Hat, Cisco Talos, Siemens, VulnCheck, and others.
• Backward-compatible. All existing CVE IDs map into GCVE under GNA-0 (e.g., CVE-2023-40224 becomes GCVE-0-2023-40224). GCVE complements CVE rather than replacing it.
• No single point of failure. GCVE is not dependent on a single government contract. GNAs define their own policies and manage their own allocations.

What this means for VRM

GCVE creates both opportunity and challenge for risk models that depend on CVE IDs to look up CVSS and EPSS data.

• EPSS blind spots. EPSS is currently keyed entirely to CVE IDs. GCVE-only vulnerabilities would have no EPSS score unless FIRST extends their model, making VRM's base calculation (CVSS x EPSS) impossible for those findings.
• Fragmentation risk. Organizations may need to monitor both CVE and GCVE feeds. Without unified deduplication, alert fatigue could worsen.
• VRM's response. For GCVE-only vulnerabilities, VRM falls back to tool-native severity with context modifiers applied, the same approach used for any finding missing CVSS or EPSS data. Internal analysis and remapping fill the gap until scoring data catches up.

Why non-CVE findings score higher

When EPSS data is missing, the base calculation (CVSS x EPSS) cannot run. Falling back to tool-native severity means the EPSS multiplier never reduces the score. The result: non-CVE findings typically land at higher criticality than equivalent CVE-backed findings because there is no exploit-probability data to refine them downward.

This is by design. Without data to quantify likelihood, the model errs on the side of caution. Teams should expect a larger proportion of non-CVE findings in the High and Critical tiers.

Recommended handling

• Use tool-native severity as the starting criticality. Most scanners, DAST, and SAST tools assign their own severity levels.
• Apply Stage 1 context modifiers on top of the tool severity. Business context still matters even without a CVE.
• Flag for internal analysis. These findings will often need static remapping: a full override (fixed criticality, no modifiers applied) or a partial override (new base criticality with modifiers still applied per system).
• Transition to full VRM scoring as data becomes available (CVE or GCVE assigned, EPSS catches up, CVSS published).

• 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 not a competing scoring system; it’s a tiny metadata addition with outsized impact.

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.

Together we can make risk modeling clearer, faster, and more aligned to how vulnerabilities are actually exploited.