CVSS (the Common Vulnerability Scoring System) is a measurement system that gives organizations a standard way to quantify the severity of software vulnerabilities. It uses a numerical grading scale of 0 (lowest) - 10 (highest) that corresponds with a severity rating.

The severity of a vulnerability refers to the damage it can do if exploited. For example, a vulnerability that enables large-scale remote code execution is likely to be given a high CVSS score.

The purpose of CVSS is to help organizations assess vulnerabilities and prioritize remediation efforts — there are tens of thousands of new vulnerabilities reported each year, and CVSS is one of several inputs security practitioners often find valuable in focusing on the most urgent fixes.

In this article, we’ll provide a quick look at CVSS, covering its makeup, scoring method, and how it helps prioritize vulnerabilities.

A Quick Look at CVSS History

CVSS was born out of a research project by the National Infrastructure Advisory Council (NIAC) and was introduced to the world in 2005. Its purpose was to create a consistent, reliable way to measure the severity of vulnerabilities in software systems. FIRST.Org, Inc., now owns and manages CVSS specifications.

CVSS has gone through several changes since it was created:

  • CVSS v1.0 (2004): The National Infrastructure Advisory Council (NIAC) introduced this version to create a standard way to score vulnerabilities, focusing on Base Metrics (core characteristics of vulnerability that don’t change over time) like Impact and Exploitability, but it lacked flexibility for real-world use.
  • CVSS v2.0 (2007): This update added more detailed metrics, making it more useful in different settings.
  • CVSS v3.x (2015, 2019): This introduced new Base Metrics like User Interaction (UI), Privileges Required (PR), and expanded the Attack Vector to include a Physical (P) value, providing more options for risk assessment. In 2019, a refined version, v3.1 was released, clarifying definitions and improving usability. 
  • CVSS v4.0 (2023): The newest version, which came out in 2023, replaced Temporal Metrics (intended to capture how vulnerabilities change over time) with the new Threat Metrics to reflect real-world exploitation scenarios. The Environmental Metrics (intended to measure organization-specific risk factors) were further refined, and Supplemental Metrics were also added to aid organizations in tailoring scores that fit their unique environments — this provides more precision in risk assessment.
Image of how CVSS scores have changed over time

CVSS Score Ranges: What the Numbers Tell Us

CVSS scores go from 0.0 to 10.0. Higher scores point to more serious vulnerabilities. These scores are often accompanied by a qualitative severity rating (None, Low, Medium, High, Critical) to facilitate rapid triage and prioritization of remediation efforts.

  • None (0.0): Has no impact.
  • Low (0.1-3.9): Has a minimal impact, often viewed as less urgent.
  • Medium (4.0-6.9): Has a moderate impact, needs attention soon.
  • High (7.0-8.9): Has a big impact and requires quick fixing or patching.
  • Critical (9.0-10.0): Has a severe impact, creates immediate and big risks.

CVSS Base Metrics: The Heart of Vulnerability Assessment

There are four main groups of metrics in CVSS 4.0: Base, Environmental, Supplemental, and Threat. (CVSS v2.0 and CVSS v3.x used three main groups of metrics: Base, Temporal, and Environmental, but, as mentioned earlier, CVSS v4.0 replaced Temporal with Threat and added the Supplemental group of metrics.)

However, the CVSS scores published by sources like the National Vulnerability Database (NVD) (and the ones provided by vulnerability management tools) rely entirely on Base Metrics. That’s because the Base Metrics group shows the core features of a vulnerability that don't change in different settings or over time; as such, Base Metrics allow for a universal starting point organizations can use for prioritization. 

Specific inputs that make up the Base Metrics group are:

  • Attack Vector (AV): Shows how an attacker can exploit the weakness. The values range from the following:
    • Network (N): You can exploit the vulnerability from a remote network location (easiest).
    • Adjacent (A): The vulnerability is exploitable from a nearby or adjacent network.
    • Local (L): You need local access to the system to exploit the vulnerability.
    • Physical (P): To exploit the vulnerability, you must physically interact with or be close to the system (hardest).
  • Attack Complexity (AC): Looks at how hard it is to exploit the weakness. A lower complexity leads to a higher score.
  • Privileges Required (PR): Points out the level of access an attacker needs to exploit the weakness.
  • User Interaction (UI): Checks if a user needs to do something for the weakness to be exploited.
  • Scope (S): Figures out if the weakness affects more than just its immediate area, like impacting a whole system instead of just one app.
  • Confidentiality, Integrity, Availability (CIA) Impact: These metrics assess how a security breach might affect the confidentiality, integrity, and availability of the system at risk. They help to gauge the potential consequences on the system's key aspects.

Here is an example of how Base Metrics would be calculated for two hypothetical vulnerabilities. (You can use the CVSS 4.0 calculator to try this for yourself.)

Example Table for Base Metrics Impact:

Attack Vector Complexity Attack Requirements Privileges Required User Interaction CIA Impact* Score
Network Low None None None High 10 (Critical)
Adjacent Low None Low None Low 5.1 (Medium)

*Note that “CIA Impact” in the table above is derived from multiple different inputs that measure both a) Vulnerable System Impact Metrics and b) Subsequent System Impact Metrics. 

In our example 10.0 score, Confidentiality, Availability, and Integrity are all scored as “high” for both Vulnerable System Impact and Subsequent System Impact. If, for example, the “Confidentiality” score for “Vulnerable System Impact Metrics” was “none” rather than “high,” the overall CVSS base score would drop to 9.3.

Similarly, for our example 5.1 score, if all CIA metrics for both Vulnerable and Subsequent System Impacts were “high” rather than “low,” the overall CVSS base score would increase to 9.4.

Other CVSS Metrics Groups

Let’s briefly examine the other Metrics Groups included in CVSS 4.0. 

Environmental Metrics

Although not included in the base score, the Environmental Metrics group lets organizations adjust the CVSS score to fit their unique environment and security needs. This customization makes sure the score shows the risk to the organization.

  • Security Requirements: Companies can change how important confidentiality, integrity, and availability (CIA) are based on what they need.
  • Modified Base Metrics: Companies can tweak the Base Metrics to match their specific situation, like having extra security measures in place.

Supplemental Metrics

​​The Supplemental Metric group gives organizations more context describing extra attributes of a vulnerability. This helps them with their decision-making process on how to respond to each metric, such as:

  • Automatable: Determines whether the vulnerability can be exploited through automated methods, increasing the risk of widespread attacks.
  • Recovery: Assesses the difficulty and complexity of restoring systems after an exploitation of the vulnerability.
  • Safety: Evaluates the potential risk to human life, health, or physical safety due to the exploitation of the vulnerability.
  • Value Density: Considers the concentration of valuable data or critical functionality within the affected component, influencing the impact of an exploit.
  • Vulnerability Response Effort: Measures the level of effort required to mitigate or remediate the vulnerability, including patch deployment and workaround implementation.
  • Provider Urgency: Reflects the urgency indicated by the vulnerability's discoverer or software provider, guiding the speed of the organization's response.

Threat Metrics

The Threat Metrics section helps organizations assess real-world dangers imposed by vulnerabilities. This is done by tracking whether an attack has occurred, a proof of concept (POC) has been developed, or if the vulnerability continues to be unreported. These metrics provide insights into the likelihood of threats, helping security teams make informed decisions to better prioritize their mitigation efforts.

  • Attacked: The vulnerability has been actively exploited in real-world attacks, which demands immediate remediations to prevent further damage.
  • Proof of Concept (POC): There is an available proof of concept, which means attackers may soon target the vulnerability, although it hasn’t been used in the wild yet.
  • Unreported: The vulnerability has been discovered, but no exploits or proofs of concepts have been reported yet, however, it still requires attention.

Using CVSS Scores to Prioritize Vulnerabilities

CVSS scores have long been an important vulnerability prioritization input, and that remains the case today. Here’s one example of how you might use CVSS alongside other prioritization inputs:

Step Input Description
1 Project Attributes Start by scoping your vulnerabilities to the projects most important to you. Leverage project labels to filter to externally facing, critical data classification, privileged access, or crown jewel applications. 
2 Dependency Depth Next, focus only on vulns impacting your direct dependencies (since these issues can generally be fixed more easily).
3 CVSS Once you have your list of vulnerabilities impacting high-priority assets and direct dependencies, filter by CVSS score; the exact threshold will depend on your organization’s risk tolerance, of course, but focusing on vulnerabilities with a score of, say, 7.0 or higher would be reasonable.
4 Fix Available Once you have a prioritized list of high-severity vulnerabilities impacting direct dependencies, you might decide to further narrow your by focusing on issues with available (or those that are either patches or minor upgrades since those will introduce the least amount of breaking changes).
5 CISA KEV Next, you might take your filtered list and focus on the vulnerabilities in the CISA KEV Catalog.
6 EPSS Score Finally, you could use EPSS as a last prioritization input before you start remediating

As you’ll see in the visual below, FOSSA’s platform makes it easy to prioritize vulnerabilities by CVSS scores and the other inputs discussed above. Sign up for our free tier to try it for yourself, or reach out to our team for a demo from our experts

Vulnerability prioritization gif