CVSS Scores Explained: What Do They Actually Mean?

A vulnerability report lands with a finding rated 9.1. Is that bad? Obviously — it's described as "critical." But what does the number actually represent, and what does it not tell you? Understanding how CVSS scores are built changes how much weight you should put on them.

What CVSS actually is

CVSS — the Common Vulnerability Scoring System — is a standardized framework for rating the severity of a vulnerability on a scale from 0 to 10. It's maintained by FIRST (the Forum of Incident Response and Security Teams) and widely used across the vulnerability database and security tooling ecosystem, including in the National Vulnerability Database.

The key thing to understand: CVSS scores the characteristics of a vulnerability in general — not whether it's actually exploitable in your specific application, in your specific configuration.

How a CVSS score is calculated

CVSS scores are built from several metric groups, the most commonly cited being the Base score, which reflects intrinsic characteristics of the vulnerability that don't change over time or context:

• Attack Vector — can it be exploited remotely over a network, or does it require local or physical access?
• Attack Complexity — how much difficulty or specific conditions does exploitation require?
• Privileges Required — does the attacker need existing access, or none at all?
• User Interaction — does exploitation require a victim to take some action?
• Scope — can the exploit affect resources beyond its own security scope?
• Impact metrics — effects on confidentiality, integrity and availability

These combine into a Base score, typically the number you see attached to a CVE. Some tools also incorporate Temporal and Environmental metrics, which adjust the score based on factors like exploit maturity or the specific environment — but Base scores are what get most commonly quoted, and they don't include that context.

What CVSS doesn't account for

This is the part that matters most in practice:

• Whether the vulnerable code path is actually reachable in your specific application
• Your specific configuration — mitigating controls that reduce real-world risk
• Business context — what data or functionality is actually behind the vulnerability
• Compensating controls — a web application firewall or network segmentation that reduces practical exploitability

Two applications can have the identical CVE, with the identical CVSS Base score, and represent very different levels of real risk, because one has the vulnerable feature exposed to the internet and the other has it behind an internal-only network boundary.

Why treating CVSS as the whole picture is a mistake

Prioritizing remediation purely by CVSS score, without layering in reachability and context, produces a predictable failure mode: teams spend effort on high-scoring findings that are barely exploitable in their actual environment, while a moderate-scoring finding that's trivially reachable by any unauthenticated user sits lower on the list than it should.

How to use CVSS well

• Treat the Base score as a starting point for triage, not a final verdict
• Layer in your own context: is this reachable, does it require authentication, what data is at stake
• Use Environmental metrics, where available, to adjust scores for your specific deployment
• Prioritize findings that combine a meaningful score with confirmed reachability, over findings that only have a high score

How does Averto fit in?

Averto doesn't stop at reporting a raw CVSS score. Findings are assessed for reachability and real-world exploitability in your actual environment, so prioritization reflects your specific risk — not just a generic severity number that may or may not apply to how the vulnerable code is actually deployed.