CVSS isn't just a score—it's a powerful language for those who know how to read it. Provided you ask it to do what it's designed to do—and nothing more.
In this guide, we'll use a CVSS v4 vector as an example. We'll see how to read it, why its Base score tells only part of the story, and then how to translate that number into a remediation decision.
What is CVSS?
The Common Vulnerability Scoring System (CVSS) is a scoring framework maintained by FIRST. It describes the technical characteristics of a vulnerability using a vector, which can correspond to a score ranging from 0 to 10.
A useful distinction to make from the outset:
- CVE (Common Vulnerabilities and Exposures) is a vulnerability identifier;
- CVSS is a way to describe and rate its severity.
CVSS provides teams with a common language. When you read “network-based attack, no privileges, no user interaction,” you gain a more precise understanding than you would from a simple “9.5.”
However, the Base score alone does not indicate whether your product is exposed to the Internet, whether an asset is critical to your business, or whether an attack has been detected. That’s why you should be wary of procedures such as “anything with a score above 9 takes priority over everything else.”
CVSS v4 Metric Groups
A CVSS vector (v4.0 or earlier versions) consists of qualitative metrics divided into three groups:
- Base: characteristics intrinsic to the vulnerability, such as the impact on the vulnerable component, whether or not the attacker must interact with the user, etc.;
- Threat or Temporal: metrics related to the threat context, such as the availability of publicly available exploit code;
- Environmental: metrics related to the context in which the exploit will occur, such as an asset’s security expectations or its position within the information system.
The Threat and Environmental metrics therefore require additional information that goes beyond the purely technical scope of the vulnerability. As such, they are almost never included in public repositories.
Thus, by using the vector and score as they are published, important aspects of the scoring are overlooked.
To fully understand the issues at stake, let’s examine the three groups one by one.
Base: What the Vulnerability Describes
The Base metrics describe, in particular, the attack conditions and potential impacts strictly from the perspective of the vulnerable system.
Attack Side:
- AV — Attack Vector: the path through which the attack can be carried out.
- AC — Attack Complexity: the complexity of the attack, particularly in relation to native security countermeasures.
- AT — Attack Requirements: the existence of prerequisites that must be met (such as a specific configuration).
- PR — Privileges Required: the privileges needed to carry out the exploit.
- UI — User Interaction: the need for user action.
On the impact side, CVSS v4 distinguishes between effects on the vulnerable system (VC, VI, VA) and on subsequent systems (SC, SI, SA). The letters C, I, and A refer to confidentiality, integrity, and availability.
This distinction is useful: compromising a device can also have consequences for other systems. The vector makes this explicitly clear.
The base metrics are always included in a CVSS vector.
Threat: What We Know About the Exploit
The Threat group, which replaces the Temporal group from previous versions, is used to account for the maturity of the exploit, particularly through Metric E (Exploit Maturity).
This information is of a different nature than the Base metrics. A vulnerability does not necessarily change its technical characteristics simply because an exploit appears. What changes is the assessment of the threat.
This group of metrics may change over time (Base metrics generally do not change) depending on the threat level and, more specifically, the existence of attacks or the presence of exploit code for the vulnerability.
Environmental: What Applies to Your Organization
Environmental metrics allow you to tailor the assessment to an organization’s specific context: the importance of confidentiality, integrity, or availability, and the characteristics of the environment in question.
This is where you must resist the temptation to copy someone else’s number.
The same vulnerability may affect, in one organization, exposed equipment running a critical service; in another, an isolated system or one used for a different purpose. The “Base” vector is common. The context in which the vulnerability manifests itself is not.
Environmental metrics make it possible not only to directly adjust the baseline metrics based on the context but also to define security expectations. This latter point, in particular, makes it possible to determine the actual criticality of the system for the organization that operates it.
Reading a CVSS v4 Vector in Practice
Let’s take the vector provided for CVE-2026-88771:
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
It is interpreted as follows:
- AV:N: The attack occurs over the network.
- AC:L: The attack complexity is low.
- AT:P: A prerequisite must be met.
- PR:N: No privileges are required.
- UI:N: No user interaction is required.
- VC:H/VI:H/VA:H: The potential impacts on the confidentiality, integrity, and availability of the vulnerable system are high.
- SC:H/SI:H/SA:H: These three potential impacts are also high for subsequent systems.
With AV:N, PR:N, and UI:N, one might interpret this as: “It’s accessible over the network, so it’s immediately exploitable anywhere.” The vector conveys something different. It specifies that a prerequisite is required for the attack to succeed.
This does not make the vulnerability benign. It means that before making a decision, you must understand what that prerequisite is and whether it is met in your environment. The vector does not replace reading the technical advisory.
The same caution applies to the score: two very severe vulnerabilities may require different responses. One may be actively exploited on an exposed asset; the other may exist only on a system not affected by the attack conditions. CVSS helps measure severity, not the probability that the threat will materialize.
Base, Threat, and Environmental: Three Levels That Should Not Be Confused
The vector above only contains Base metrics. As mentioned earlier, it lacks important considerations for understanding the risk itself.
Although CVSS is a severity score, it incorporates risk factors such as threat. For CVE-2026-88771, the vector above could become:
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:A.
This addition indicates that the vulnerability is actively being exploited.
Based on this information, we can develop a working scenario to determine the following metrics specifically for our organization:
- How do we expose Citrix NetScaler or ADC?
- What are our security requirements for the system running one of the vulnerable products? Is there any sensitive data accessible through this system? Must this system remain absolutely available for our business operations?
Make CVSS the starting point of triage, not its conclusion
We didn’t mention the CVSS score in the example above. The vector told us a great deal, and we can infer a high level of severity from the details, given all the information at our disposal.
Here, we have a CVSS Base score of 9.5.
So this is a critical score. But since more than 50% of vulnerabilities published in the CVE system are rated as high or critical, this vulnerability doesn’t stand out from the noise.
If the team automatically processes all scores above 9 before examining exploitation indicators and its environment, it risks spending three days on a very noisy queue. Meanwhile, another issue—such as the one in our example—deserves an immediate response.
Ultimately, the right questions to ask during the triage process go beyond the severity score and are as follows.
1. What exactly does the score describe?
As we’ve seen, the score alone is very limited. You need to look at the vector, not just the score. You need the metrics to make an informed decision.
2. What do we know about exploitation?
Look for verifiable information: vendor advisories, observed exploitation, presence in the KEV (Known Exploited Vulnerabilities), and threat intelligence. EPSS can supplement this picture by estimating the probability of exploitation based on its own model.
3. Are we actually affected?
Confirm the affected versions and configurations. Then assess the asset’s exposure and its role within the information system. An incomplete inventory makes even the best score difficult to use.
4. What decision do we make, and by when?
Patch the vulnerability, implement a risk mitigation measure, investigate a potential compromise, or document why the response can wait: the right decision depends on the preceding factors.
We must also take into account the fact that a decision is never final. The situation may change, and we must be prepared to adapt.
A method like SSVC can help formalize this decision-making process. Its value lies not in producing yet another number, but in leading to an explicit, understandable, and revisable decision.
Conclusion: Four Key Steps Before Deploying the Patch
When a new CVE enters the queue, four steps are essential in the qualification process:
- Review the CVSS vector, its version, and its conditions, rather than focusing solely on the score;
- Look for signs of exploitation, without confusing the absence of such signs with the absence of risk;
- Verify the local context: affected product, exposure, and importance of the asset;
- Decide on and document an appropriate action, assign a responsible party, and set a timeline tailored to this context.
The CVSS remains valuable. It provides a common language for discussing severity. The problem arises when we rely on it alone to drive the entire remediation pipeline.
This is precisely the task we simplify at Sentibee: bringing together information on vulnerabilities, exploitation signals, and product context to help teams build a roadmap of actions, rather than a list of scores to reduce.
To explore further: https://www.first.org/cvss/calculator/4.0