What Is CVSS (Common Vulnerability Scoring System)?

What Is CVSS?

The Common Vulnerability Scoring System (CVSS) is a standardized framework for rating the severity of software vulnerabilities. Maintained by the Forum of Incident Response and Security Teams (FIRST), CVSS assigns a numeric score from 0.0 to 10.0 to each vulnerability based on its technical characteristics. The score is accompanied by a qualitative severity rating: None (0.0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0). CVSS provides a common language for discussing vulnerability severity across vendors, tools, and organizations.

CVSS scores appear in the National Vulnerability Database (NVD), vendor security advisories, vulnerability scanner reports, and threat intelligence feeds. They are the most widely used metric for communicating how severe a vulnerability is, and many organizations use them as the primary input for prioritizing remediation. This ubiquity makes CVSS an essential concept for anyone involved in vulnerability management, but it also creates a risk: treating CVSS scores as the complete picture of risk rather than one input among several.

The system has evolved through multiple versions. CVSS v2 was widely used for over a decade. CVSS v3.0 and v3.1 introduced refined metrics and scoring adjustments. CVSS v4.0, released in 2023, made further changes to address limitations in previous versions. Understanding how CVSS works, what it measures, and what it does not measure is essential for using it effectively within a vulnerability management program.

How CVSS Scoring Works

CVSS uses three groups of metrics to produce a score. Each group captures a different dimension of vulnerability severity.

Base Metrics

Base metrics capture the intrinsic characteristics of a vulnerability that are constant across environments and over time. These are the metrics that the NVD and vendor advisories publish, and they produce the Base Score that most people refer to when they cite a CVSS score. Base metrics evaluate two categories: exploitability and impact.

Exploitability metrics describe how the vulnerability is exploited. The attack vector indicates where the attacker must be positioned (network, adjacent network, local, or physical). The attack complexity describes the conditions beyond the attacker's control that must exist for exploitation to succeed (low or high). In CVSS v4.0, attack requirements are separated from attack complexity to better distinguish between environmental conditions and technical difficulty. Privileges required indicates the level of access the attacker needs before exploitation (none, low, or high). User interaction describes whether a human victim must take an action (such as clicking a link or opening a file) for exploitation to succeed.

Impact metrics describe the consequences of successful exploitation. Confidentiality impact measures the effect on information disclosure. Integrity impact measures the effect on data modification. Availability impact measures the effect on system availability. Each is rated as none, low, or high. In CVSS v4.0, subsequent system impact metrics are added to capture effects on systems beyond the directly vulnerable component.

The Base Score is calculated from these metrics using a formula that weights each factor. A vulnerability with network-based attack vector, low complexity, no privileges required, no user interaction, and high confidentiality/integrity/availability impact scores at the top of the range (9.0-10.0). A vulnerability requiring physical access, high complexity, high privileges, and user interaction with low impact scores near the bottom.

Temporal Metrics

Temporal metrics capture characteristics that change over time. Exploit code maturity describes the availability and reliability of exploitation techniques: from theoretical (no known exploit) to high (reliable, weaponized exploit code is publicly available). Remediation level describes the current state of available fixes: from official fix (vendor patch available) to unavailable (no fix exists). Report confidence indicates how certain the vulnerability information is: from unknown to confirmed.

Temporal metrics adjust the Base Score up or down based on the current exploitation landscape and fix availability. In practice, temporal metrics are less widely used than base metrics because they require ongoing updates as the situation evolves. Many NVD entries and scanner reports display only the Base Score without temporal adjustments.

Environmental Metrics

Environmental metrics allow organizations to customize the score based on their specific environment. Modified base metrics let the organization adjust exploitability and impact values to reflect local conditions, such as network segmentation that reduces the effective attack vector or data classification that changes the confidentiality impact assessment. Security requirements metrics (confidentiality, integrity, and availability requirements) allow the organization to weight the impact metrics according to the asset's business importance.

Environmental metrics produce a score tailored to the organization's context, which is more useful for prioritization than the generic Base Score. A vulnerability with a Base Score of 9.0 might have an Environmental Score of 5.0 in an organization where the affected component is on an isolated network segment handling non-sensitive data. Despite the value of environmental scoring, few organizations invest the effort to calculate environmental scores for individual vulnerabilities because the data requirements (asset criticality, network topology, compensating controls) are substantial and must be maintained as the environment changes.

What CVSS Measures and What It Does Not

CVSS measures the intrinsic severity of a vulnerability based on its technical characteristics. A CVSS 9.8 indicates that the vulnerability is technically severe: it can be exploited remotely, without authentication, with low complexity, and with high impact on confidentiality, integrity, and availability. This information is useful for understanding the potential consequence of exploitation.

CVSS does not measure the likelihood of exploitation. A vulnerability with a CVSS Base Score of 9.8 but no known exploit code, no observed threat actor interest, and no proof-of-concept publication is less likely to be exploited in the near term than a vulnerability with a CVSS score of 7.5 that has a weaponized exploit actively used in ransomware campaigns. CVSS treats both as "critical" and "high" respectively, without capturing this critical distinction.

CVSS does not account for the business context of the affected asset. A CVSS 9.0 vulnerability on a server processing customer payment data represents very different risk than the same score on a developer's sandbox environment. Without environmental metrics (which are rarely calculated), CVSS treats both equally.

CVSS does not consider the presence of compensating controls. A vulnerability that is mitigated by a web application firewall, network segmentation, or endpoint detection still receives the same Base Score. The score describes the vulnerability in isolation, not the vulnerability in the context of the organization's defensive posture.

CVSS in Practice

Most vulnerability management programs use CVSS as a sorting mechanism. Scanner results are sorted by CVSS score, and remediation teams work from the top of the list. This approach has the advantage of simplicity: critical first, then high, then medium, then low. It is also the default in most scanning tools, which makes it the path of least resistance.

The problem is that CVSS-only prioritization creates an overwhelming remediation queue. In a typical enterprise environment, 10-20% of scan findings are rated critical or high by CVSS. Across thousands of assets, this produces hundreds or thousands of critical and high findings, all appearing to demand immediate attention. Without additional context, the team cannot distinguish between findings that represent real, imminent risk and findings that are technically severe but practically harmless in context.

The result is vulnerability fatigue. Teams cannot remediate hundreds of critical findings simultaneously, so they either work through the list mechanically (regardless of actual risk) or become overwhelmed and slow down across the board. Critical findings that are genuinely dangerous wait in the same queue as critical findings that pose no practical threat, receiving no special attention.

Effective use of CVSS treats it as one input among several. CVSS provides the severity dimension. Exploit Prediction Scoring System (EPSS) provides the likelihood dimension. The CISA Known Exploited Vulnerabilities (KEV) catalog provides confirmed exploitation status. Asset criticality data provides business context. Combining these inputs produces a prioritization model where the top items represent genuine, actionable risk rather than the longest list of high-scoring findings.

Understanding CVSS Score Distributions

Analyzing the distribution of CVSS scores across the NVD reveals patterns that have practical implications for vulnerability management programs. The distribution is heavily skewed toward higher scores. A disproportionate number of CVEs receive scores in the 7.0-9.0 range, while relatively few receive scores below 4.0. This skew occurs because vulnerabilities serious enough to be assigned a CVE and published tend to have meaningful impact characteristics, and the CVSS formula weights impact heavily in the score calculation.

For vulnerability management programs, this distribution means that CVSS-based severity tiers produce uneven workloads. The "critical" tier (9.0-10.0) is relatively manageable in size. The "high" tier (7.0-8.9) is often the largest, containing a disproportionate share of all findings. The "medium" tier (4.0-6.9) is moderate, and the "low" tier is small. Programs that commit to remediating all critical and high findings within short SLAs may find the high tier alone exceeds their remediation capacity, which is why additional prioritization within the high tier (using EPSS, KEV, and asset context) is essential.

CVSS Across Versions

Organizations should be aware that CVSS scores for the same vulnerability can differ between CVSS v2, v3.1, and v4.0. The NVD historically displayed v2 scores and has been transitioning to v3.1 and v4.0. Scanner vendors may use different CVSS versions depending on what is available for each CVE. When comparing scores across tools or over time, verifying that the same CVSS version is being used prevents misleading comparisons.

CVSS v4.0 introduced several improvements, including the separation of attack requirements from attack complexity, the addition of subsequent system impact metrics (capturing impact on systems beyond the directly vulnerable component), and the introduction of supplemental metrics such as Automatable (can the exploitation be automated?) and Recovery (can the system recover after exploitation?). These additions provide more granular information for prioritization, but they also increase the complexity of score interpretation. Organizations should evaluate whether their tools support CVSS v4.0 scoring and whether their prioritization processes can use the additional metrics.

The transition between CVSS versions is gradual. Many CVEs in the NVD still have only v3.1 scores, and some older CVEs have only v2 scores. Vulnerability management platforms should handle multiple CVSS versions gracefully, normalizing scores where possible and flagging findings where version discrepancies might affect prioritization. Ultimately, the specific CVSS version matters less than recognizing the system's fundamental limitation: severity is only one dimension of risk, and CVSS scores of any version should be combined with exploitation likelihood data and business context for effective prioritization.