CVSS is the most widely used yardstick for vulnerabilities — and the most frequently misunderstood. With version 4.0, FIRST has fixed some of its best-known weaknesses. What does not change, however, is the point that matters most for device manufacturers.
What CVSS 4.0 does differently
The most important changes compared to 3.1:
Scope is gone. The binary and notoriously inconsistently applied Scope metric has been replaced. In its place is the distinction between the vulnerable system and subsequent systems — impacts are recorded separately for both, instead of disappearing into a yes/no flag.
New base metric "Attack Requirements" (AT). It captures prerequisites beyond the attack vector: specific configurations, race conditions, other conditions that must be met. Previously, such constraints ended up vaguely in the complexity metric.
User Interaction has three levels. Where 3.1 only knew "none" and "required", 4.0 distinguishes more finely how much a user action actually has to contribute.
Explicit naming of score variants. CVSS-B, CVSS-BT, CVSS-BE and CVSS-BTE make visible which metric groups went into a number. This addresses a real practical problem: the value communicated as "the CVSS score" was almost always the pure Base Score — the environmental and threat metrics were simply never assessed.
Temporal is now called Threat. A renaming that makes the intent clearer.
Supplemental Metrics. A new, optional group: Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort and Provider Urgency. Important to know: none of these values feeds into the score. They carry additional information but do not change the number.
Macrovectors instead of a formula. The score is calculated via a lookup table rather than a closed-form equation. Invisible to users, relevant to implementers.
What matters for field devices
Two points are particularly interesting for manufacturers of industrial devices.
The first is Safety as a Supplemental Metric. The fact that FIRST included this dimension at all acknowledges what has always been true in the OT world: vulnerabilities in devices with a protective function have a damage dimension that IT vulnerabilities do not. But: it is supplemental. It does not change the score. If you want to reflect safety relevance in your prioritization, you have to do so outside of CVSS.
The second is the separation of vulnerable and subsequent systems. That is exactly the typical constellation in the field: the vulnerability sits in the communication module, the impact arises in the plant behind it.
The point that 4.0 does not solve either
CVSS rates a vulnerability, not your risk. The Base Score describes properties of the vulnerability itself, regardless of where it is deployed, how exposed the device is, which protective function depends on it, and which compensating countermeasures take effect in the zone in front of it.
This leads to a rule that is often violated in practice: A CVSS score is an input to your risk assessment, not its result. A vulnerability with a Base Score of 9.8 in a function your product does not even enable is low priority for you. One with 5.3 on the only interface that parameterizes your protective function is not.
Delegating prioritization to the Base Score means you have not carried out the risk assessment, but outsourced it — to someone who does not know your product.
How to combine both sensibly
In an assessment under IEC 62443, CVSS has a clearly defined place: as a structured description of the likelihood side of a known vulnerability. It replaces neither threat modeling — which finds scenarios for which no CVE exists yet — nor the impact assessment in the context of your product.
In practice, this means: adopt CVSS values, actually fill in the environmental metrics instead of passing on the Base Score, and feed the result into your own rating as one input among several. The decision on what gets fixed first still lies with those who know the device and how it is used.
Sources
This article was originally published in German on the Alsensio Cybersecurity Hub.
