CVSS provides numerical vulnerability severity ratings, but it's frequently misunderstood. Learn what CVSS actually measures and where it falls short.
The Common Vulnerability Scoring System attempts to provide consistent severity ratings for security vulnerabilities. In practice, CVSS scores are frequently misunderstood and misused. This guide explains what CVSS actually measures and where it falls short.
CVSS provides a numerical score from 0 to 10 representing vulnerability severity. The current version, CVSSv3.1, calculates this score from eight base metrics. These metrics cover how the vulnerability can be exploited (attack vector, attack complexity, privileges required, user interaction required), what the impact is (confidentiality, integrity, availability), and whether the vulnerability can affect resources beyond its immediate scope.
The metrics feed into a formula that produces the base score. The formula is publicly documented, though few people calculate scores manually. Most use automated calculators provided by NIST or vendors.
CVSS scores map to severity ratings. Scores from 0.1 to 3.9 are considered Low. Scores from 4.0 to 6.9 are Medium. Scores from 7.0 to 8.9 are High. Scores from 9.0 to 10.0 are Critical. These ranges are arbitrary but widely adopted.
A score of 6.9 and 7.0 might have minimal practical difference, but they cross the medium/high boundary. Organizations that use score thresholds for prioritization need to understand this arbitrariness. The boundary between categories doesn't represent a fundamental change in vulnerability nature.
Beyond the base score, CVSS includes temporal and environmental metrics that organizations can use to adjust scores. Temporal metrics reflect factors that change over time, like exploit availability, remediation status, and confidence in the report. Environmental metrics let organizations adjust scores based on their specific environment, like how critical the affected system is or what compensating controls exist.
In practice, most organizations only use base scores. Calculating temporal and environmental scores requires effort that few teams invest. Base scores are readily available from vendors and vulnerability databases. Custom scoring requires security expertise and time that many organizations lack.
CVSS measures vulnerability severity in isolation. It doesn't consider whether the vulnerable system is internet-facing, how many systems are affected, whether compensating controls exist, the value of data on the system, or your organization's threat model. A CVSS 9.8 vulnerability in an isolated lab system might be low risk for your organization. A CVSS 5.0 vulnerability in your authentication system might be critical.
Scores aren't directly comparable across vulnerability types. A CVSS 7.5 in a web application isn't necessarily equivalent to a CVSS 7.5 in an operating system kernel. The scoring considers different factors, and practical exploitation difficulty varies significantly.
High scores don't always mean easy exploitation. A vulnerability might score CVSS 9.0 because it has high potential impact, even if exploitation requires extensive preconditions that are rarely present in practice. The score reflects what could happen if exploited, not how likely exploitation is.
The Attack Vector metric causes frequent scoring errors. Network means the vulnerability is remotely exploitable over a network without any preconditions. This is the worst case for exploitability and generates the highest scores.
Adjacent requires the attacker to be on the same network segment. They need to be on the same VLAN or WiFi network. This isn't remotely exploitable over the internet, which significantly reduces risk for many organizations.
Local requires local access to the vulnerable system. The attacker must already have a foothold, either through physical access or prior compromise. Physical requires physical access to the vulnerable device itself.
I regularly see scores that classify local vulnerabilities as network exploitable, dramatically inflating the severity score and misrepresenting the actual risk.
Privileges Required addresses what privileges an attacker needs on the target system before exploiting the vulnerability. None means an unprivileged attacker can exploit it directly. Low means basic user privileges are needed. High means administrative privileges are required.
User Interaction addresses whether exploitation requires a victim to take some action like clicking a link or opening a file. None means the vulnerability can be exploited without victim interaction. Required means someone must do something for exploitation to succeed.
These are independent metrics. A vulnerability might require no privileges but need user interaction, like many cross-site scripting issues. Another might require high privileges but no user interaction, like some local privilege escalation bugs.
The Scope metric significantly affects scores. A scope change means the vulnerability allows an attacker to affect resources beyond the vulnerable component's security scope. The classic example is a virtual machine escape that allows an attacker to impact the hypervisor and other VMs.
Most vulnerabilities don't involve scope changes. Don't assume they do just because the impact is significant. Scope changes represent a specific technical scenario where security boundaries are crossed.
Some vulnerabilities don't fit CVSS well. Denial of service issues have availability impact captured by CVSS, but it doesn't distinguish between a DoS that crashes a service once and one that permanently consumes all resources requiring manual intervention. Practical severity differs significantly.
Information disclosure gets basic treatment. CVSS doesn't capture what information is disclosed. Exposing server version numbers scores similarly to exposing user credentials, even though the risk differs dramatically.
Logic flaws often don't map well to CVSS categories. A flaw that lets users get free products might have low CVSS scores by the technical metrics but high business impact. CVSS wasn't designed to capture business logic issues.
Scores come from various sources. NIST's National Vulnerability Database scores CVEs, though with significant delay that can be weeks or months. Vendors often publish scores when releasing security updates. Researchers might calculate scores when reporting vulnerabilities. Your own team can calculate scores based on your specific environment.
Different parties sometimes assign different scores to the same vulnerability. There's no single authoritative score. The NVD score might differ from the vendor score, and both might differ from your internal assessment.
Treat CVSS as input to your risk assessment, not the final output. Use it to inform prioritization, but don't automate remediation decisions based solely on CVSS scores without considering context.
Calculate base scores consistently for all your vulnerabilities to enable comparison. Adjust based on environmental factors like exposure, compensating controls, and system criticality. Use scores to categorize and initially prioritize, but review high-impact vulnerabilities regardless of CVSS score. Some critical issues score lower than their actual risk warrants.
Don't automatically reject findings below a certain CVSS threshold. Don't treat CVSS 7.0 as fundamentally different from 6.9. Don't assume all Critical vulnerabilities need immediate attention without considering your specific situation. Never ignore business context in favor of automated scoring.
Some organizations use alternative scoring systems. SSVC (Stakeholder-Specific Vulnerability Categorization) focuses on decision making rather than abstract severity. EPSS (Exploit Prediction Scoring System) predicts the probability a vulnerability will be exploited in the wild based on observed exploit activity. Some organizations develop internal severity matrices incorporating business factors.
These aren't replacements for CVSS. They're supplements that address CVSS limitations. CVSS remains useful for standardized communication about vulnerability severity, even if it shouldn't be your only input to risk decisions.
CVSS v4.0 was released in 2023 but adoption remains slow. It adds metrics for operational technology, safety impacts, and better handles complex attack chains. But most organizations still use CVSSv3.1 because that's what vendors and databases provide.
When v4.0 becomes standard, the core principles remain the same. It's a severity metric, not a risk metric. The same cautions about overreliance and need for contextual assessment apply.
When scoring vulnerabilities you discover, err on the side of objectivity. Inflating scores to emphasize importance backfires when stakeholders learn to discount your assessments. Use the official CVSS calculator rather than guessing. The scoring rubric has nuances that aren't obvious without careful reading.
Document your reasoning for each metric. "Network attack vector because it's exposed on the intranet" explains your thinking if someone questions the score later. This documentation proves more valuable than the score itself for understanding the actual risk.
CVSS doesn't capture exploit difficulty beyond basic complexity metrics. It doesn't account for attack prerequisites beyond privileges and user interaction. It doesn't consider the value or sensitivity of affected data. It doesn't account for compensating controls you've implemented. It doesn't reflect attacker motivation or capability requirements.
Organizations that treat CVSS as comprehensive risk assessment fundamentally misunderstand its purpose. It's one input into risk decisions, providing a standardized way to communicate severity. It's not the complete picture of risk, and it was never intended to be.
A technical comparison of vulnerability disclosure approaches from security.txt to full bug bounty platforms. Understanding the security trade-offs at each maturity level.
Clear scope in your vulnerability disclosure policy determines what researchers should test. Get it wrong and you'll discourage valid research or deal with unwanted testing.
GDPR creates obligations around data breaches that intersect with vulnerability management. Understanding this intersection prevents compliance problems.
Get the latest security research insights and vulnerability disclosure best practices delivered to your inbox.