[ Common Vulnerabilities and Exposures ]
What is a CVSS Score?
A CVSS (Common Vulnerability Scoring System) score is an open, standardized framework used to measure and communicate the severity of software vulnerabilities. Managed by FIRST (Forum of Incident Response and Security Teams), it provides numerical scores from 0.0 to 10.0, allowing security teams to consistently evaluate and prioritize threats.
While CVSS is the industry standard for communicating vulnerability severity, it should not be used as the sole basis for remediation decisions. A CVSS score reflects the technical characteristics and potential impact of a vulnerability, but it does not account for factors such as active exploitation, asset criticality, business impact, or an organization’s specific environment unless environmental metrics are applied. As a result, security teams typically combine CVSS with exploit intelligence, threat context, and asset data to prioritize vulnerabilities.
The scoring scale:
CVSS scores are translated into qualitative categories to help organizations quickly assess the danger level:
- None: (0.0)
- Low: (0.1) – (3.9)
- Medium: (4.0) – (6.9)
- High: (7.0) – (8.9)
- Critical: (9.0) – (10.0)
CVSS metric groups:
The score is generated using different metric groups that assess the vulnerability from various perspectives (the latest framework, CVSS v4.0, includes four groups):
- Base metrics: The core, intrinsic qualities of a vulnerability (e.g., how easy it is to exploit and what kind of impact it has on confidentiality, integrity, and availability).
- Threat (temporal) metrics: Factors that change over time, such as whether an exploit code is currently available or if a patch exists.
- Environmental metrics: How the vulnerability specifically impacts your unique business environment, taking into account critical assets and mitigations.
- Supplemental metrics: Additional descriptive attributes, such as safety hazards or programmatic impacts.
This is part of a series of articles about common vulnerabilities and exposures
In this article:
- How Is a CVSS Score Calculated: CVSS Metric Groups
- CVSS v3.1 vs. CVSS v4.0
- How Security Teams Use CVSS Scores
- Limitations of CVSS Scores
- How to Prioritize Vulnerabilities Beyond CVSS
How Is a CVSS Score Calculated: CVSS Metric Groups
Base Metrics
Base metrics form the foundation of CVSS scoring and reflect the intrinsic qualities of a vulnerability that are constant over time and across environments. These metrics include attack vector (how the vulnerability is exploited), attack complexity (the conditions required to exploit it), privileges required (the level of access needed), user interaction (whether user participation is necessary), scope (if exploitation affects resources beyond the vulnerable component), and the impact metrics: confidentiality, integrity, and availability. Together, these metrics describe the technical severity and exploitability of a vulnerability.
By focusing on factors that do not change with time or environment, base metrics provide a consistent baseline for comparing vulnerabilities. Security teams and vendors use these metrics to establish a starting point for risk analysis, ensuring that the severity assessment remains stable despite external changes. This consistency supports patch prioritization and vulnerability management, especially in environments with many potential threats.
Threat (Temporal) Metrics
Threat, or temporal, metrics adjust the CVSS score based on factors that can change over time, such as the existence of active exploits, the availability of remediation, or changes in public awareness. These metrics include exploit code maturity (how easily the vulnerability can be exploited), remediation level (the availability and effectiveness of fixes), and report confidence (the credibility of the vulnerability report). As these elements evolve, the overall risk associated with a vulnerability can increase or decrease.
Temporal metrics support real-time risk assessment, allowing organizations to adapt their response as threats develop. For example, if reliable exploit code becomes available or a vulnerability gains widespread attention, its temporal score may increase, signaling a higher priority for remediation. This aspect of CVSS scoring helps organizations respond to emerging threats and allocate resources as conditions change.
Environmental Metrics
Environmental metrics allow organizations to tailor CVSS scores to their infrastructure, business priorities, and risk tolerance. These metrics consider factors such as the importance of affected assets, the presence of mitigating controls, and the potential impact on the organization’s environment. By adjusting the base and temporal scores with environmental considerations, organizations can generate a more accurate representation of the vulnerability’s risk within their context.
This customization is important for large or complex organizations where the same vulnerability may pose different levels of risk depending on deployment scenarios or business functions. Environmental metrics help security teams focus on vulnerabilities that could have the greatest operational or financial impact and align remediation efforts with organizational priorities.
Supplemental Metrics
Supplemental metrics, introduced in CVSS v4.0, provide additional context that does not fit into the other metric groups. These metrics cover attributes such as safety impact, automation potential, or other relevant factors not previously captured. They address gaps in earlier versions of CVSS by including information that can influence prioritization but is not directly tied to technical severity or exploitability.
Including supplemental metrics improves the flexibility and accuracy of CVSS scoring. For example, a vulnerability with low technical impact but high safety implications in an industrial control system can be flagged appropriately. These data points help ensure that security assessments account for a broader range of real-world concerns.
CVSS v3.1 vs. CVSS v4.0
CVSS v4.0, introduced in November, 2023, builds on CVSS v3.1 by improving how vulnerabilities are evaluated and providing more context for prioritization. The updated framework introduces new metrics, refines existing ones, and expands environmental scoring to help organizations produce assessments that better reflect real-world risk.
- Threat metrics replace temporal metrics: CVSS v4.0 replaces temporal metrics with threat metrics that emphasize active exploitation and the current threat landscape. It also introduces supplemental metrics for factors such as safety impact and automation potential.
- Base metrics provide greater precision: The base metric model includes more granular attack requirements and impact measurements, making it easier to distinguish vulnerabilities that received similar scores in CVSS v3.1 but present different levels of risk.
- Environmental scoring is more flexible: Environmental metrics allow organizations to better account for asset criticality, business impact, and compensating controls, resulting in scores that more accurately reflect their operating environment.
- Both versions remain relevant: Although CVSS v3.1 is still widely used in vulnerability databases and security tools, adoption of CVSS v4.0 continues to grow. Organizations should be familiar with both versions because vulnerability reports may use either standard depending on the reporting source.
How Security Teams Use CVSS Scores
Vulnerability Prioritization
Vulnerability prioritization is one of the primary uses of CVSS scores. Security teams rely on these scores to identify which vulnerabilities pose the greatest risk and should be addressed first. By focusing on high and critical vulnerabilities, typically those with scores of 7.0 or higher, organizations can reduce the likelihood of successful exploitation.
Effective prioritization requires more than reviewing CVSS scores alone. Teams often combine CVSS with contextual information, such as asset value, business impact, and known exploit activity, to refine their process. This helps ensure that limited resources are directed toward the vulnerabilities that matter most.
Patch Management SLAs
Patch management service level agreements (SLAs) often use CVSS scores to define timelines for remediation. Organizations may set policies requiring that critical vulnerabilities be patched within 24 or 48 hours, while lower-severity issues are addressed on a longer schedule. This approach uses the standardized severity assessment of CVSS to establish expectations and accountability for patching.
By tying patch management SLAs to CVSS scores, organizations can maintain a consistent response to vulnerabilities across teams and systems. This supports risk reduction, regulatory compliance, and internal audit requirements. Regularly reviewing and updating SLAs in light of changing threats and CVSS updates helps maintain effective vulnerability management.
Compliance and Reporting
CVSS scores play a role in compliance and reporting frameworks, serving as a benchmark for demonstrating due diligence in vulnerability management. Many regulations and standards, such as PCI DSS, HIPAA, and NIST, require organizations to identify and remediate vulnerabilities based on severity. Using CVSS provides an objective measure that auditors and regulators can verify.
Organizations also use CVSS scores in internal and external security reports to track progress, communicate risk, and justify resource allocation. Consistent use of CVSS in reporting supports transparency and accountability.
Vendor Advisories and Vulnerability Databases
Security teams use CVSS scores published in vendor advisories and vulnerability databases to assess newly disclosed vulnerabilities. Sources such as the National Vulnerability Database (NVD), MITRE CVE records, and vendor security bulletins typically include CVSS scores alongside technical details about affected products, attack methods, and available mitigations. These scores provide a standardized way to evaluate severity across vendors and technologies.
By incorporating CVSS data from trusted sources into vulnerability management tools and workflows, organizations can automate parts of the identification and prioritization process. Security teams can filter for high-risk vulnerabilities, track newly disclosed issues, and determine which systems require attention. This reduces the time between vulnerability disclosure and remediation.
Limitations of CVSS Scores
While CSVV is useful and widely adopted, it has significant limitations when used on its own.
CVSS Does Not Equal Exploitability
A common misconception is that a high CVSS score automatically means a vulnerability is easy to exploit. CVSS measures severity based on technical characteristics and potential impact. It does not answer whether an attacker could exploit the vulnerability on a specific asset.
That question is narrower than it sounds. Exploitability asks whether the conditions the vulnerability depends on are actually met in your environment, whether the affected feature is enabled, whether the vulnerable configuration is set, and whether an attacker can control the input that reaches the vulnerable code. If any required condition is absent, the vulnerability cannot be exploited there regardless of its score.
Public exploit code, exploit maturity, and active exploitation campaigns are a separate question again. They describe how difficult exploitation would be and how likely it is to be attempted, which matters once you already know exploitation is possible. Frameworks such as EPSS and vendor advisories are useful for that, but they measure what is happening in the world rather than what is possible on your systems.
CVSS Does Not Include Business Context by Default
CVSS base scores are designed to be universal, which means they do not account for an organization’s business priorities, asset value, or operational requirements. The same vulnerability may have very different consequences depending on where it exists. A medium-severity vulnerability on a mission-critical production system could present more risk than a high-severity vulnerability on an isolated test server.
Environmental metrics can help adjust scores to reflect local conditions, but many published CVSS scores do not include these customizations. Organizations should evaluate vulnerabilities in the context of business impact, regulatory requirements, data sensitivity, and system criticality instead of relying only on generic severity ratings.
Scores Can Vary Between Analysts
Although CVSS provides a standardized framework, scoring involves human judgment. Analysts may interpret vulnerability details differently, particularly when assessing factors such as attack complexity, required privileges, scope, or potential impact. These differences can lead to variations in scores assigned by vendors, researchers, or vulnerability databases for the same issue.
To improve consistency, CVSS documentation includes detailed scoring guidance and examples. However, some variation remains, especially when information about a vulnerability is incomplete or evolving. Organizations should treat CVSS scores as a reference point rather than an absolute measure of risk and review supporting technical details when making remediation decisions.
How to Prioritize Vulnerabilities Beyond CVSS
1. Confirm Exploitability, Then Weigh Likelihood
CVSS measures the potential severity of a vulnerability, but it does not indicate how likely the vulnerability is to be exploited. Security teams should consider factors such as the availability of public exploit code, active exploitation, and threat intelligence reports when determining remediation priorities. A medium-severity vulnerability that attackers are actively exploiting may deserve more immediate attention than a critical vulnerability with no known exploitation activity.
Many organizations use indicators such as EPSS scores and threat intelligence feeds to estimate exploit probability. These are global signals, so they work best in sequence rather than in isolation. First confirm the vulnerability can be exploited on the affected asset at all. Then use exploit maturity and attack complexity to judge how difficult that would be, which is what drives likelihood. Then weigh impact against what the affected system can actually reach, change, or take down.
2. Account for Data Sensitivity and Privilege Level
The value of the affected system and the type of data it handles can influence the actual risk posed by a vulnerability. A flaw affecting a database that stores customer records, financial information, or intellectual property typically warrants higher priority than the same flaw on a non-production system.
Privilege levels also matter. Vulnerabilities that provide administrative access, domain-level control, or unrestricted access to sensitive resources can have a greater impact than those that affect low-privilege accounts. Evaluating both data sensitivity and privilege escalation potential helps align remediation efforts with business risk.
3. Prioritize Vulnerabilities That Enable Attack Chains
Attackers often combine multiple vulnerabilities and misconfigurations to achieve their objectives. A vulnerability that appears low or medium severity on its own may become significant if it can be used as part of an attack chain that leads to privilege escalation, lateral movement, or data exfiltration.
Security teams should analyze vulnerabilities within the broader context of their environment rather than evaluating each issue independently. Understanding how vulnerabilities interact with systems, identities, and network paths can reveal risks that severity scores alone may not capture. Addressing vulnerabilities that enable common attack paths can reduce overall exposure.
4. Factor in Patch Availability and Remediation Complexity
Remediation planning should consider not only the severity of a vulnerability but also the practicality of fixing it. Vulnerabilities with readily available vendor patches and straightforward deployment processes can often be addressed quickly with minimal operational disruption.
In contrast, some vulnerabilities require extensive testing, application changes, downtime, or infrastructure modifications before fixes can be implemented. When remediation is complex, organizations may need to implement temporary compensating controls such as network segmentation, access restrictions, or monitoring until a permanent fix is available. Factoring in remediation effort helps create realistic vulnerability management plans.
5. Use a Vulnerability Management Solution to Turn Prioritization Into Action
Modern environments often contain thousands of vulnerabilities across code, servers, cloud resources, and applications. Manually evaluating and tracking these issues can be time-consuming. Vulnerability management solutions help organizations automate discovery, risk assessment, prioritization, remediation tracking, and reporting.
These platforms typically combine CVSS scores with additional context such as asset criticality, exploit intelligence, exposure data, and compliance requirements. By consolidating vulnerability information into a single workflow, security teams can focus on the issues that present the highest risk and ensure remediation efforts are completed. This turns vulnerability prioritization into an ongoing, measurable risk reduction process.
How to Prioritize Vulnerabilities Beyond CVSS with Maze
Going beyond CVSS requires understanding whether a vulnerability is actually exploitable in your specific environment, not just how severe it looks in isolation. Maze uses AI agents that replicate the workflows of expert security engineers to investigate code and cloud vulnerabilities, remove false positives, identify the vulnerabilities that truly matter, and route one-click remediation actions to the right people, so security teams can focus their limited time on the risks that could lead to a real breach.
Key capabilities of Maze:
- Investigate every vulnerability in context: Maze’s AI agents deeply investigate each vulnerability in the context of your cloud environment, compensating controls, and business, replicating the reasoning an expert security engineer would apply rather than relying on a generic severity score.
- Ignore non-exploitable vulnerabilities with confidence: Because over 90% of vulnerabilities cannot be exploited in the context of a given environment, Maze lets you confidently set aside non-exploitable findings and automatically generates reports for auditors to document those decisions.
- Identify the vulnerabilities that matter to your business: In-depth analysis of both technical and business context surfaces the vulnerabilities most likely to lead to a serious breach, so prioritization reflects real risk instead of raw CVSS numbers.
- Respond fast without project-managing remediation: Intelligent workflows generate high-impact mitigation and remediation plans and route one-click actions to the right people, cutting the manual coordination that slows response.
- Deploy in minutes, agentlessly: Getting started takes under five minutes and requires only a read-only role in your cloud environment and an API connection to your existing vulnerability scanners, with no agents to install on your machines.
Ready to move beyond severity scores and focus on what’s actually exploitable? Learn how Maze investigates cloud vulnerabilities.