VRM 3.x + CNA collaboration

The Future of VRM: Partnering with CVE Issuers

Small additions at CVE creation time can dramatically improve downstream risk modeling accuracy in VRM 3.x. By adding standardized exploitability hints, CNAs can help every consumer differentiate real-world risk per asset type.

Collaborate on exploitability tags → Get VRM 3.x updates

Built on CVSS (impact) and EPSS (likelihood) Adds exploitability shape to asset-aware risk scoring

Why CVE tags matter

VRM 3.0 blends CVSS (impact), EPSS (likelihood), and asset/business context (sensitivity, criticality, lifecycle, exposure). The next frontier is tiny, standardized exploitability “shape” metadata added during CVE creation. This does not replace scoring systems; it adds a high-value, low-friction hint about how the vulnerability is typically exploited and enables VRM 3.x to differentiate risk per asset type.

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.

The three exploitability tags

Every vulnerability typically aligns with one or more exploit paths. These three tags are the core primitives.

#LocalApplication

Definition:

                Vulnerabilities where exploitation typically requires local code
                execution or user interaction, such as opening a file, visiting
                a webpage, or executing an untrusted binary.
              

Characteristics:

Often starts with phishing, malicious documents, drive-by sites, or user actions.
Includes local privilege escalation requiring code already running on the system.

Examples:

Chrome RCE requiring user to visit a malicious webpage.
Office document macro exploit delivered by phishing.
Local privilege escalation where the attacker must already be running code.

#RemoteService

Definition:

                Vulnerabilities in services or applications that listen on a
                network port and accept inbound connections.
              

Characteristics:

Classic server-side exposure.
Relevant to internet-facing, DMZ, and internal services.

Examples:

RCE in a VPN appliance.
Web server or API endpoint exploitable without authentication.
RDP/SSH vulnerabilities reachable over the network.

#PhysicalAccess

Definition:

                Vulnerabilities where exploitation requires physical presence or
                direct hardware-level/proximity interaction with the device.
              

Characteristics:

Requires plugging in a peripheral, accessing a port, or being near the device.
Often applies to kiosks, medical devices, embedded systems, IoT, field equipment, laptops, and specialized hardware.

Examples:

USB-based privilege escalation requiring physical insertion of a device.
JTAG/UART debug modes that bypass authentication.
Bootloader exploitation only accessible at power-on with console access.
NFC/Bluetooth/WiFi-proximity attacks requiring attacker presence near the device.

How these tags feed into VRM 3.0 and 3.x

VRM uses these tags as context-aware modifiers to reflect how assets are actually attacked.

Workstations

Elevate #LocalApplication (users browse, click, open files).
Reduce #RemoteService (endpoints should have few/no exposed services, host firewalls isolate inbound traffic).
#PhysicalAccess depends on environment (office vs public kiosk).

Servers

Elevate #RemoteService (core attack surface for business-critical services).
Reduce #LocalApplication (servers don’t run browsers or productivity apps).
#PhysicalAccess typically low risk unless the device is field-deployed.

Specialized devices (kiosks, medical devices, POS, OT/IoT)

Elevate #PhysicalAccess due to public/field exposure.
Balance #LocalApplication and #RemoteService based on architecture.

Human-friendly examples:

A Chrome RCE (#LocalApplication) is high-risk on employee laptops but almost irrelevant on a hardened backend server.
An unauthenticated RCE in a web server (#RemoteService) is critical for servers but meaningless on a workstation that doesn’t run such a service.
A USB-based takeover (#PhysicalAccess) is negligible on locked racks in a datacenter but severe on a public kiosk or patient-facing medical device.

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

Roadmap for VRM 3.x

VRM continues to evolve as we partner with CNAs, vendors, and researchers.

Where we are

VRM 3.0 = CVSS × EPSS × Context.
VRM 3.1 = richer lifecycle/business modifiers.
VRM 3.2 = vulnerability aging, habits, attack-surface pressure.

Where we are going

VRM 3.x = exploitability tag integration for per-asset-type risk scoring.
Collaborating with CNAs 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.

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.

Partner with VRM → Subscribe for VRM 3.x updates or reach out to co-design standardized exploitability tagging.