CVSS Scores Explained: A Guide to Severity Ratings

The Common Vulnerability Scoring System, or CVSS, is the industry-standard framework for rating the severity of software vulnerabilities. It provides a numerical score from 0.0 to 10.0, allowing security professionals to translate a complex flaw into a single, understandable metric for prioritization. This score helps organizations triage an overwhelming number of vulnerabilities and decide which ones to fix first.

What Is the Common Vulnerability Scoring System?

Managed by the Forum of Incident Response and Security Teams (FIRST.org), CVSS was created to provide a universal, open standard for communicating the characteristics and severity of software vulnerabilities. Before CVSS, different security vendors and researchers used their own proprietary, often subjective, language and scoring systems. This created confusion and made it difficult for IT teams to compare and prioritize threats from different sources.

CVSS solves this by acting as a common language. It provides a transparent and repeatable formula for scoring vulnerabilities based on their intrinsic characteristics. A vulnerability in a specific version of Apache Struts, for example, will have the same base CVSS score whether it's reported by a government agency, a security vendor, or an independent researcher.

Crucially, a CVSS score represents severity, not risk. This is the most misunderstood aspect of the system. Severity is a measure of the vulnerability itself—how easy it is to exploit and what impact an exploit could have. Risk, on the other hand, is severity combined with business context. The risk posed by a vulnerability depends on the value of the affected asset, the presence of mitigating controls, and the likelihood of an actual attack. CVSS is just one input into that larger risk equation.

The Three Metric Groups

A CVSS score is not a single number pulled from thin air. It's derived from three distinct metric groups: Base, Temporal, and Environmental. While most people only ever see the final Base Score, understanding all three is key to using CVSS effectively.

The Base Score: Intrinsic Qualities

The Base Score reflects the static, unchanging characteristics of a vulnerability. These are the qualities inherent to the flaw itself, independent of time or how it's deployed. This score is calculated using several metrics that fall into two categories: Exploitability and Impact.

Exploitability Metrics measure how easy it is for an attacker to exploit the flaw:

• Attack Vector (AV): How must the attacker be positioned to exploit the vulnerability? Is it over the Network (N), from an Adjacent (A) network, Local (L) to the machine, or with Physical (P) access?
• Attack Complexity (AC): How complex is the attack? Is it Low (L), meaning it can be performed at will, or High (H), requiring conditions beyond the attacker's control?
• Privileges Required (PR): What level of privileges does the attacker need on the target system *before* the exploit? None (N), Low (L), or High (H)?
• User Interaction (UI): Does the exploit require a user to take some action, like clicking a link? None (N) or Required (R)?

Impact Metrics measure the consequences of a successful exploit, using the classic CIA triad of security:

• Confidentiality (C): The impact on the confidentiality of data. Could an attacker read sensitive information? (High, Low, or None).
• Integrity (I): The impact on data integrity. Could an attacker modify data? (High, Low, or None).
• Availability (A): The impact on the availability of the system. Could an attacker cause a denial of service? (High, Low, or None).

These metrics combine to produce the familiar 0.0-10.0 score. For example, a vulnerability that can be exploited remotely over the internet (AV:N) by anyone (PR:N) without user interaction (UI:N) and which gives the attacker full control over the system (C:H, I:H, A:H) will score as Critical.

The Temporal Score: A Vulnerability's Lifecycle

The Temporal Score modifies the Base Score based on factors that change over time. It acknowledges that a vulnerability's threat profile isn't static. A flaw with no public exploit is less urgent than one being actively used by malware.

Key temporal metrics include:

• Exploit Code Maturity (E): Is there a functional exploit available? This ranges from Unproven to Proof-of-Concept to Functional (like a Metasploit module) to High (automated and widely available).
• Remediation Level (RL): Is a fix available? This can be an Official Fix, a Temporary Fix, a Workaround, or Unavailable.
• Report Confidence (RC): How certain is it that the vulnerability is real and accurately described? It can be Confirmed, Reasonable, or Unknown.

The Temporal Score can lower a vulnerability's priority (e.g., when a patch is released) or dramatically increase it (e.g., when a working exploit appears on GitHub). This is why a vulnerability that was a Medium threat last month might become a Critical priority today.

The Environmental Score: It's All About Context

The Environmental Score is the final, and most important, step in making CVSS relevant to a specific organization. It allows a security team to modify the Base and Temporal scores based on their unique environment. This is where severity is translated into actionable risk.

This involves two key activities:

1. Modifying Base Metrics: An organization can adjust the base metric values. For instance, a vulnerability with a "Low" confidentiality impact might be recategorized as "High" if the affected server stores mission-critical intellectual property. A flaw requiring "Local" access might be less of a concern if that system is physically secured and has no remote access.
2. Security Requirements (CR, IR, AR): An organization can weigh the importance of confidentiality, integrity, and availability for a specific asset. A public-facing web server's availability might be rated as "High," while a development server's might be "Low."

Calculating the Environmental Score is the most difficult part of using CVSS, as it requires a deep understanding of your own assets. However, it is also the most valuable, as it helps you focus resources on the vulnerabilities that pose the greatest actual risk to your business operations.

From Numbers to Ratings

To make the scores easier to digest, they are mapped to qualitative severity ratings. While organizations might adjust these, the standard ranges for CVSS v3.1 and v4.0 are:

Security teams often use these ratings to create Service Level Agreements (SLAs) for patching. For example, a policy might state that "Critical" vulnerabilities must be patched within 7 days, "High" within 30 days, and so on.

The Limitations of CVSS: Why It's Not the Whole Story

Despite its widespread adoption, relying solely on the CVSS Base Score is a common and dangerous mistake. The system has inherent limitations that can lead to poor prioritization if not understood.

First, there's a strong bias toward the Base Score. Many vulnerability scanners and feeds only show the Base Score, ignoring the crucial Temporal and Environmental context. This leads to "vulnerability fatigue," where security teams are faced with a long list of "Critical" flaws with no clear way to decide which one to tackle first.

Second, CVSS does not include data on active exploitation. A vulnerability with a 10.0 score that is difficult to exploit and has never been seen in the wild is far less urgent than a 7.5 vulnerability that is currently being used by ransomware gangs. This is the single biggest gap in the CVSS model. To address this, security teams should look at other resources. Learning what CISA's KEV catalog is and why it matters is a critical step, as it lists vulnerabilities that are confirmed to be actively exploited.

Third, the score itself can be misleading without context. A browser vulnerability might require significant user interaction (lowering the score) but can be triggered with a simple phishing email, making it highly effective in the real world. Similarly, many of the most damaging attacks in recent years involved chaining multiple "Medium" or "High" vulnerabilities, not just exploiting a single "Critical" one. The context of a vulnerability, such as whether it is a [zero-day flaw](/posts/what-zero-day-means), is often more important than its numerical score.

Building a Risk-Based Vulnerability Management Program

CVSS is an essential tool, but it's just a starting point. A mature vulnerability management program goes beyond the score to prioritize based on actual risk. This involves a multi-layered approach.

1. Ingest and Aggregate Data: Start with CVSS scores provided by vulnerability scanners, software vendors, and national vulnerability databases like NIST's NVD.

1. Enrich with Threat Intelligence: This is the most critical step. Overlay the CVSS data with intelligence on which vulnerabilities are actually being exploited. This can come from CISA's KEV, commercial threat intelligence feeds, and frameworks like the Exploit Prediction Scoring System (EPSS), which provides a probability score (0-100%) on whether a vulnerability will be exploited in the next 30 days.

1. Apply Business Context: This is the practical application of the Environmental Score. You must know what you have. Use a Configuration Management Database (CMDB) or asset inventory to understand which systems are business-critical, which ones face the internet, and which ones store sensitive data. A CVSS 9.8 on an isolated test server is less important than a 6.5 on your primary payment processing database.

1. Prioritize, Remediate, and Verify: Combine these data points to create a true risk-based priority list. Your top priorities will be actively exploited vulnerabilities on critical, internet-facing systems. From there, you can work your way down the list. This prioritized list becomes the foundation of a robust remediation strategy. For a deeper dive into this process, see our guide on [how to build a patch management process](/posts/patch-management-process-guide). By moving from a severity-based to a risk-based model, organizations can focus their limited resources on fixing the flaws that matter most, significantly reducing their chances of a breach.