CVSS

What CVSS measures and how a score is built

CVSS is published by FIRST, the Forum of Incident Response and Security Teams. Its specification turns metrics about one vulnerability into a score from 0.0 to 10.0 plus a vector string that records the inputs. Versions 3.1 and 4.0 share the same qualitative bands:

• None: 0.0
• Low: 0.1 to 3.9
• Medium: 4.0 to 6.9
• High: 7.0 to 8.9
• Critical: 9.0 to 10.0

The metrics sit in groups. Base describes intrinsic qualities that stay constant over time and across environments: how the flaw is reached, how complex it is to exploit, what privileges and user interaction it needs, and its impact on confidentiality, integrity and availability. Temporal (called Threat in v4.0) covers traits that change over time, such as exploit maturity. Environmental covers what is specific to one organization. Version 4.0 also adds Supplemental metrics that never change the score. Most published scores are Base only, labelled CVSS-B in v4.0.

Reading a vector and looking up a score

A vector string lists every input. FIRST's v3.1 user guide uses this example:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

It reads: reachable over the network, low complexity, no privileges, no user interaction, scope unchanged, high confidentiality impact, no integrity or availability impact. The formulas in the 3.1 specification give 7.5, which is High.

The NVD record of a CVE shows the score, and the vendor may publish its own. For Log4Shell the NVD API returns a Primary and a Secondary entry:

curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228'   | jq -r '.vulnerabilities[0].cve.metrics.cvssMetricV31[]
      | [.source,.type,.cvssData.baseScore,.cvssData.baseSeverity] | @tsv'

Records carry different metric keys, so list them first with .metrics | keys. The vector is often more useful than the number: AV:L or PR:H means the attacker needs local access or high privileges, which lowers urgency on a server where you control both.

What a score does not tell you

FIRST's CVSS user guide states that the Base score measures severity and "should not be used alone to assess risk." A Base score assumes a reasonable worst case and knows nothing about your server: whether the vulnerable service is installed, reachable from the internet, or being attacked right now.

Common mistakes:

• Patching only Critical and ignoring a Medium that is already exploited.
• Treating a Critical in software you do not run, or expose only on localhost, as an emergency.
• Comparing scores from different sources or versions as if they were identical.
• Assuming threat data was applied. In v4.0 an undefined Exploit Maturity is treated as Attacked, the worst case.

Evidence of exploitation has to come from elsewhere. EPSS, also from FIRST, estimates the probability that a CVE is exploited in the next 30 days, and the CISA KEV catalog lists vulnerabilities with confirmed exploitation.

Using CVSS alongside KEV in a patch routine

Treat CVSS as a sorting key, not a verdict. A workable order for a small fleet:

1. Is it in the KEV catalog and in software you run? Exploitation is confirmed, so take the emergency path whatever the score.
2. Otherwise, is the vulnerable component reachable from the internet and rated High or Critical? Patch in the next patch window or sooner.
3. Everything else follows the routine update cycle.

A CVSS score carries no patch deadline, so set your own target for each tier and write it down. Remember that a rating can change: a Medium becomes urgent the day a public exploit appears, which is why a weekly review beats a one-time sort.

The full routine, from automation to verifying that a fix is really running, is in our server patch management guide, and the KEV step is walked through in the KEV priority guide.

Related terms: Patch management, CISA KEV catalog, N-day exploit, Zero-day exploit, Patch window.