Wiz
All articlesVulnerability Management

What is CVSS? Common vulnerability scoring system explained

Wiz Experts Team
AWS VM Cheat SheetWatch 12-min demo
Key takeaways about CVSS:

  • CVSS measures technical severity, not risk: The Common Vulnerability Scoring System (CVSS) assigns a score from 0.0 to 10.0 based on a vulnerability's intrinsic characteristics. While this score indicates how severe a vulnerability is technically, it does not tell you if it is actually exploitable in your specific environment.

  • Base Scores are often misleading without context: Most organizations rely solely on the Base Score provided by NVD because calculating Environmental metrics manually is difficult at scale. This leads teams to prioritize high-severity findings that may not be exposed, while potentially missing lower-scored vulnerabilities that are actively at risk.

  • True prioritization requires runtime context: A high CVSS score on an isolated, stopped workload poses less risk than a medium score on an internet-facing database with sensitive data. Effective prioritization correlates CVSS scores with environmental factors like network exposure, identity permissions, and data proximity.

  • Wiz transforms severity into actionable risk: Wiz enriches CVSS data with deep cloud context through its Security Graph. This allows teams to focus on the vulnerabilities that create real attack paths, rather than just chasing high severity scores.

What is CVSS?

CVSS (Common Vulnerability Scoring System) is an open framework that assigns numerical scores to software vulnerabilities based on their technical severity characteristics. This score helps security teams communicate how dangerous a vulnerability could be if exploited, but it does not indicate whether exploitation is likely or even possible in a specific environment.

The FIRST (Forum of Incident Response and Security Teams) maintains and publishes the CVSS standard to provide a standardized method for rating IT vulnerabilities. Without this common language, every vendor and researcher would describe severity differently, making it impossible to compare risks across different systems and tools.

Adoption of CVSS is widespread across the cybersecurity industry. The National Vulnerability Database (NVD) attaches CVSS scores to over 200,000 CVE entries, major software vendors include them in security advisories, and commercial vulnerability scanners use them as the default severity metric. This standardization allows security teams to ingest data from multiple sources and maintain a consistent understanding of severity.

The Ultimate Vulnerability Management Playbook

Actionable steps to identify, assess, and mitigate AWS vulnerabilities, ensuring your cloud infrastructure is protected.

Why is CVSS important for vulnerability management?

Before CVSS was standardized, vulnerability management was chaotic, with vendors using subjective terms like "high," "critical," or "important" without consistent definitions. CVSS solved this by providing a quantitative, repeatable way to measure severity, allowing organizations to compare vulnerabilities across diverse technologies and communicate risk using a common language. When a researcher discovers a new flaw, the CVSS score immediately communicates its potential impact to vendors, downstream users, and security teams.

Compliance frameworks and audit requirements heavily rely on this standardized language. PCI DSS requires addressing high-risk vulnerabilities within 30 days, while FedRAMP mandates 30-day remediation for High findings. Many organizations build internal SLAs around CVSS bands, such as 'remediate all Critical vulnerabilities within 7 days.' However, mature security programs recognized by frameworks like SOC 2 and ISO 27001 increasingly incorporate exploit intelligence and asset criticality alongside CVSS thresholds, providing auditors with defensible prioritization rationale beyond raw severity scores.

For most organizations, CVSS serves as the primary filter for vulnerability prioritization, with security teams typically setting policies to patch vulnerabilities with scores of 7.0 or higher. However, relying on CVSS alone often leads to alert fatigue. Because CVSS treats every instance of a vulnerability with the same scoreregardless of whether the asset is internet-facing or buried in a private subnet,teams can be overwhelmed by "Critical" alerts that pose no immediate danger. This creates a tension between severity and priority: CVSS tells you how bad a vulnerability is technically, but it cannot tell you if it matters right now in your specific environment.

CVE vs CVSS: What is the difference?

It is common to confuse CVE and CVSS, but they serve distinct purposes. CVE (Common Vulnerabilities and Exposures) is the unique identifier or "name" for a vulnerability, such as CVE-2024-12345.

CVSS is the numerical score that describes the severity of that vulnerability. A single CVE can have multiple CVSS scores associated with it, depending on the version of CVSS used (v3.1 vs v4.0) or differing assessments from software vendors versus the NVD.

Think of CVE as the "who" and CVSS as the "how bad." The CVE program provides the standard list of identifiers, while NVD and other authorities provide the CVSS analysis for those identifiers.

How does CVSS work?

A CVSS assessment consists of three distinct metric groups: Base, Temporal, and Environmental. While the final score depends on which of these groups are applied, most public sources only provide the Base Score.

This means that what most organizations see is a theoretical maximum severity, not a score tailored to their specific reality. Understanding the components of these groups is key to interpreting the score correctly.

CVSS metric groups

Each group refines the score further, moving from a generic technical assessment to a specific organizational risk. In practice, however, most organizations rarely see beyond the Base Score due to the complexity of calculating the other metrics manually.

Base metrics: The intrinsic severity score

The Base Score is derived from two sub-groups: Exploitability and Impact. Exploitability metrics measure how easy it is to exploit the flaw, including the Attack Vector (AV), which defines if the attack can be launched remotely or requires physical access.

Other Exploitability metrics include Attack Complexity (AC), which measures conditions beyond the attacker's control, and Privileges Required (PR), which indicates the level of access an attacker needs. User Interaction (UI) determines if a user must take action, such as clicking a link, for the exploit to succeed.

Impact metrics measure the consequence of a successful exploit. These include Confidentiality (C), Integrity (I), and Availability (A), often referred to as the CIA triad. The Scope metric in CVSS v3.x further defines whether exploiting the vulnerability affects resources beyond the vulnerable component itself.

Temporal metrics: Adjusting for current conditions

Temporal metrics adjust the Base Score based on factors that change over time. Exploit Code Maturity measures whether functional exploit code exists and how reliable it is, lowering the score if no exploit is available.

Remediation Level adjusts the score based on whether an official patch, temporary workaround, or no fix is available. Report Confidence reflects the degree of certainty that the vulnerability exists and is technically accurate. In practice, these metrics are often omitted from public databases, leaving teams with static Base Scores.

Environmental metrics: Your organization's context

Environmental metrics allow organizations to customize the score to their specific environment. Modified Base Metrics let you adjust the Base values if your specific configuration mitigates the vulnerability (e.g., if a vulnerability requires network access but the asset is air-gapped).

Impact Subscore Modifiers allow you to define the importance of Confidentiality, Integrity, and Availability for the specific affected asset. While Environmental metrics solve the "one size fits all" problem in theory, calculating them manually for thousands of assets is operationally impossible for most teams.

How CVSS scores are calculated?

The CVSS calculator combines these metric values using weighted formulas to produce a final score between 0.0 and 10.0. This score is often represented as a vector string, a compressed text string that records the values assigned to each metric.

For example, a vector string like CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H tells you exactly how the score was derived. Here's how to interpret it:

  • Exploit friction (AV + AC + PR + UI): Network-accessible (AV:N), low complexity (AC:L), no privileges needed (PR:N), no user interaction required (UI:N), meaning this vulnerability is easy to exploit remotely

  • Scope (S): Unchanged (S:U), so impact stays within the vulnerable component

  • Business impact (C/I/A): High confidentiality, integrity, and availability impact, meaning successful exploitation fully compromises the system

When triaging, check exploit friction first: vulnerabilities requiring physical access (AV:P) or high privileges (PR:H) are harder to weaponize than network-accessible, no-auth flaws.

You can use the NVD CVSS Calculator to input these values and see how changes to metrics affect the final score.

Beyond CVSS: Context-aware vulnerability prioritization

Modern vulnerability management has evolved beyond simple severity sorting. By layering runtime context on top of CVSS scores, organizations can identify the small percentage of vulnerabilities that represent immediate danger.

Combining CVSS with exploit intelligence

Combining CVSS with threat intelligence helps answer the question, "Is anyone actually using this?" Tools like EPSS and the CISA Known Exploited Vulnerabilities (KEV) catalog provide this temporal context.

A CVSS 7.0 vulnerability listed in KEV often warrants faster action than a CVSS 9.5 vulnerability with 0.1% EPSS probability and no known exploits. This intelligence helps teams focus on threats that are real right now.

Adding environmental context automatically

Modern cloud security platforms automate the calculation of environmental factors. They continuously assess network exposure to determine if an asset is reachable from the internet, analyze identity permissions to see if the asset has privileged access to other parts of the cloud, and check for data proximity to sensitive resources.

In practice, the goal is a single, shared view of severity + exposure + blast radius, so cloud security, AppSec, and SecOps teams prioritize the same queue instead of reconciling multiple dashboards. This unified context eliminates the handoffs and disagreements that slow remediation.

This automation effectively delivers the promise of CVSS Environmental metrics at scale, without manual effort.

Attack path analysis and toxic combinations

True risk arises from "toxic combinations" of factors: a vulnerability, plus network exposure, plus high privileges. Attack path analysis identifies these chains to show how an attacker could actually compromise your environment.

A useful prioritization rule: focus on issues where reachability (network exposure) + permission (identity privileges) + impact (data or workload criticality) intersect. For example:

  • CVSS 5.0 SQL injection + internet-facing + access to customer PII = critical emergency

  • CVSS 9.8 RCE + stopped instance + no network path + no sensitive data access = low priority

This intersection-based approach mirrors how graph-driven security platforms identify the 2–5% of vulnerabilities that represent actual attack paths.

Wiz's approach to contextualizing CVSS

Wiz automates the environmental context that traditional CVSS usage lacks. By performing agentless scanning across your entire cloud estate, Wiz identifies vulnerabilities and instantly correlates them with the runtime reality of your workloads.

The Wiz Security Graph maps the relationships between vulnerabilities, internet exposure, identities, and sensitive data. This allows Wiz to identify toxic combinations, such as a "Medium" severity vulnerability that becomes critical because it sits on an exposed machine with admin keys.

This approach allows security teams to deprioritize the noise of high-CVSS findings that have no exploit path, and instead focus on the findings that represent real, actionable risk. By transforming vulnerability management from a list of scores into a map of attack paths, teams can fix what matters most.

Get a demo to see how Wiz connects CVSS scores with exposure context and attack paths across your cloud environment, transforming severity lists into prioritized risk maps.