What Is CVSS? Understanding Severity Scores
Author: Domeny.ForSale editorial team Published
In brief: CVSS (Common Vulnerability Scoring System) is an open, international standard for assessing the technical severity of vulnerabilities: security flaws in software and systems. Its score from 0 to 10 helps compare vulnerabilities, but does not, on its own, determine the risk to a particular business. When prioritising fixes, you also need to check factors such as how accessible the affected system is, the importance of the data it processes, and evidence of actual exploitation.
What does CVSS measure, and what does it leave out?
CVSS describes the conditions required to exploit a vulnerability and the potential consequences of a successful attack. It considers factors such as how an attacker can reach the vulnerable component, the privileges required, and whether user interaction is necessary. It also assesses the impact on confidentiality, integrity and availability: protecting information against disclosure, unauthorised changes and loss of access, respectively.
The standard is developed and maintained by FIRST, an organisation bringing together security incident response teams. A consistent way of describing vulnerabilities makes it easier for software vendors, administrators and analysts to compare assessments. However, this does not mean that every vulnerability with the same score requires the same response.
Vulnerability severity is not the same as risk. A technical assessment describes the properties of a flaw. Risk also depends on whether the business uses the vulnerable feature, who can access it, and what the consequences of a system compromise would be.
How should you interpret the scale from 0 to 10?
CVSS v3.1 and v4.0 use the following qualitative rating ranges:
| CVSS score | Severity rating |
|---|---|
| 0.0 | None |
| 0.1–3.9 | Low |
| 4.0–6.9 | Medium |
| 7.0–8.9 | High |
| 9.0–10.0 | Critical |
A score of 9.8 indicates a vulnerability of critical severity, not a 98 per cent probability of an attack. Nor does it indicate how much time remains before a breach or a deadline by which the flaw will definitely be exploited.
The scale should not be treated as a simple multiplier of losses, either: a vulnerability rated 8.0 will not necessarily cause twice as much damage as one rated 4.0. The number comes from the standard’s calculation rules, rather than an estimate of business consequences.
The version, vector and type of assessment matter
Alongside the score, look for the CVSS version number and the vector, a text representation of the values assigned to individual metrics. For example, the prefix CVSS:3.1/ identifies the version of the standard, while AV:N within a vector indicates a network attack vector. The complete vector lets you check how the final score was calculated.
A base assessment describes the fundamental properties of a vulnerability. Do not assume that it accounts for your infrastructure configuration or the latest information about attacks. What the score covers depends on the metric groups used:
- CVSS v3.1 distinguishes between Base, Temporal and Environmental metrics. Temporal metrics account for factors including the maturity of available exploit techniques and the availability of a fix.
- CVSS v4.0 distinguishes between Base, Threat, Environmental and Supplemental metrics. Threat metrics concern exploit maturity, while Environmental metrics allow the conditions in a particular organisation to be taken into account. Supplemental metrics provide additional context but do not change the score.
Scores from different versions of the standard should not be compared without checking the underlying assumptions. Differences between a vendor’s assessment and an assessment in a vulnerability database may also stem from different interpretations of the attack conditions. In that situation, comparing the vectors and their justifications is more useful than looking at the numbers alone.
How can you use CVSS to prioritise fixes?
Imagine two vulnerabilities. The first has a score of 9.8 and affects a component in an isolated test environment. The second has a score of 8.1 but affects a publicly accessible, customer-facing system, and credible advisories confirm that it is being actively exploited.
The second flaw may require a more urgent response despite its lower score. This does not undermine CVSS: it simply shows that a technical assessment is one part of the decision. An isolated environment should not automatically be considered safe either: you need to check the actual access paths.
Use this short procedure when assessing a particular report:
- Confirm the vulnerability: check the product, version, configuration and conditions described in the vendor’s advisory.
- Verify the assessment: check the CVSS version, the vector, and whether the score is a base score or includes additional metrics.
- Assess exposure: establish whether the vulnerable feature is accessible from the internet, from the internal network, or only locally.
- Check the threat context: look for confirmation of active attacks and available methods of exploiting the flaw.
- Choose an action: plan an update. If an immediate update is not possible, consider restricting access or disabling the vulnerable feature as recommended by the vendor.
Confirm the current assessment and remediation recommendations in the vendor’s official advisory, and consult the FIRST documentation for metric definitions. For the next report, write one sentence beside the CVSS score explaining its priority in your environment—for example: “Public-facing system with customer data, confirmed attacks, urgent update required.”
See also: What is KSEF?
Read also
