Vulnerability fundamentals

What Is CVSS? Understanding Severity Without Confusing It with Risk

How CVSS v4.0 works and why manufacturing plants must add operational context.

Why a vulnerability score exists

When many vulnerabilities are published, security teams need a consistent way to communicate technical severity. The Common Vulnerability Scoring System, or CVSS, provides such a method. It is maintained by FIRST, an international organization supporting incident response teams. CVSS produces a numerical score from 0.0 to 10.0 and, when used, a qualitative label such as Low, Medium, High or Critical.

CVSS is not a report of damage that has occurred, and a CVSS Base score is not a measurement of a particular factory’s risk. NIST’s National Vulnerability Database and FIRST both emphasize this distinction. The score describes technical characteristics under defined scoring rules; the site’s exposure, existing safeguards and operational consequences still matter.

What the score categories mean

FIRST’s CVSS v4.0 specification defines the following qualitative severity ranges: None is 0.0, Low is 0.1–3.9, Medium is 4.0–6.9, High is 7.0–8.9, and Critical is 9.0–10.0. These categories are useful for communication, but the number alone cannot tell an OT team whether a fix is safe to install during an active production run.

The four metric groups in CVSS v4.0

Base metrics describe intrinsic properties of the vulnerability, such as how it may be reached, whether privileges or user interaction are required, and what its exploitation can affect. CVSS v4.0 separates impacts to the vulnerable system from impacts to subsequent systems, which is useful when considering consequences beyond the affected component.

Threat metrics reflect conditions that may change over time, such as the maturity or evidence of exploitation. Environmental metrics allow an organization to account for characteristics of its own deployment and the importance of affected systems. Supplemental metrics can add context, including safety-related considerations, without changing the calculated score.

The shorthand matters. CVSS-B identifies a Base score. CVSS-BT incorporates Base and Threat information. CVSS-BE incorporates Base and Environmental information; CVSS-BTE includes all three. A vector string records the selected metrics so another analyst can understand what the score represents. A statement such as “this has a 9.8 score” is incomplete if the scoring version and source are not identified.

CVSS v4.0: score ranges and metric groups

Explanatory figure
  • Group 01BaseIntrinsic technical characteristics
  • Group 02ThreatEvidence and maturity of exploitation
  • Group 03EnvironmentalConditions in your own deployment
  • Group 04SupplementalAdditional context such as safety
  • None: 0.0
  • Low: 0.1–3.9
  • Medium: 4.0–6.9
  • High: 7.0–8.9
  • Critical: 9.0–10.0
FIRST publishes the severity ranges and metric definitions. Scores must be considered alongside real plant exposure and operational context.

A real example and its limits

CVE-2021-44228, the Log4j vulnerability commonly called Log4Shell, is documented in the NVD. Its published records include CVSS information and links to underlying advisories; the NVD lists a CVSS v3.1 Base score of 10.0 (Critical). That critical technical issue warrants investigation, but a factory must still determine which installed applications actually include affected versions, what functions they perform, and whether the vulnerable functionality can be reached.

A patch for an engineering workstation, an internet-facing server and a production controller may demand different installation arrangements. They should be evaluated using accurate asset data, vendor guidance and responsible operations staff rather than a universal “patch highest score first” rule.

What to consider in a manufacturing environment

Manufacturers should supplement CVSS with the verified affected version, exploitation intelligence, the device’s network exposure, the quality of compensating controls, and the potential consequences for production continuity and safety. A remotely exploitable vulnerability on an exposed support server could require prompt action. A vulnerability in a highly isolated device may call for a scheduled vendor-approved fix and interim monitoring. Neither conclusion should be assumed without evidence.

CVSS v4.0 expressly provides Environmental metrics to help capture deployment-specific factors, but a complete factory risk decision can still involve additional issues outside CVSS, such as contractual obligations, downtime costs and operational approval processes.

A sound prioritization process

Use CVSS as a common severity language, not as a substitute for engineering judgment. Read the vector and scoring version, confirm the asset and software version, check authoritative exploitation reports and vendor mitigations, consult OT personnel on safe remediation, and document the decision. When a security tool displays scores from different CVSS versions, avoid comparing them without noting the version.

The best use of CVSS is to make technical vulnerability information more understandable while leaving room for the operational reality of the plant.

Official sources and further reading

The resources below support the technical information discussed. Review current vendor advisories and applicable national law before making operational or compliance decisions.

DTSecLabs / Industrial cybersecurity knowledge

Educational resource | Published Jun 17, 2025

Back to all blogs