Back to glossary

CVSS

2 min read

In vulnerability management, CVSS is the Common Vulnerability Scoring System, an open framework for describing the characteristics and severity of a vulnerability as a number. It is a starting point for prioritisation and not a measure of your risk, because the score is a property of the flaw and risk is a property of your environment.

July 24, 2026
Compartir:

How it works

The current version is CVSS v4.0, published by FIRST in November 2023. It scores a catalogued vulnerability and reorganises the metrics into four groups. Base describes the intrinsic characteristics of the flaw: how it is reached, how hard it is to exploit, what privileges and user interaction it needs, and what it does to confidentiality, integrity and availability, distinguishing the vulnerable system from the systems downstream of it. Threat replaces the older temporal group and carries the current state of exploitation. Environmental lets you restate the base metrics for your own deployment and weight the impact by what the asset is worth to you. Supplemental adds descriptive attributes such as recovery effort and automatability, which do not change the number.

The part people skip is that the base score is explicitly defined as the score before your context is applied. Publishing a base score and calling it a risk rating is using the framework against its own documentation.

What goes wrong

Prioritising by base score alone, which is still the default behaviour in most estates we see, produces a queue sorted by how bad a flaw could be for somebody, with no reference to whether it will be used against you. Two signals fix that and neither of them is part of CVSS. EPSS gives a probability that a flaw will be exploited in the wild in the near term. The KEV catalogue records that exploitation has actually been observed. A high base score with negligible exploitation probability and no confirmed use is a different job from a medium score sitting in the confirmed catalogue on an internet-facing host.

The second failure is treating the number as objective. Two competent assessors regularly produce different vectors for the same flaw, because scope, privileges required and user interaction are judgement calls. The vector string is the useful artefact, not the number, because it can be argued with.

Where this shows up in an audit

Every finding we issue carries a vector and the reasoning behind the contested metrics, so a client can recompute it for their own environment rather than accept ours. We rate against the environment we tested, and where a client’s asset value changes the answer we say so. We do not publish scores taken from a vendor advisory for a different deployment, and we do not quote severity ranges we cannot source from our own reports.

¿Quieres ver cómo trabajamos en Asperis Security?

Agenda 30 minutos con uno de nuestros especialistas. Revisamos tu stack y te decimos qué conviene probar primero.