CVSS v3.1 Severity Score Mechanics AI-pedia

The Common Vulnerability Scoring System version 3.1 (CVSS v3.1) is an open technical standard designed to capture the principal characteristics of a software, hardware, or firmware vulnerability and translate those characteristics into a numerical score ranging from 0.0 to 10.0. Maintained by the Forum of Incident Response and Security Teams (FIRST), CVSS provides an open and standardized method for cross-organizational communication regarding the technical severity of software defects.

A CVSS score does not measure risk directly. Instead, it measures technical severity based on the intrinsic qualities of a flaw under constant conditions. A complete score is calculated through a collection of predefined metrics grouped into three distinct categories: Base, Temporal, and Environmental. The Base group reflects the inherent qualities of the vulnerability that remain unchanged over time and across different deployment environments; the Temporal group reflects factors that evolve during the vulnerability's lifecycle, such as exploit availability and patches; and the Environmental group customizes the assessment to a specific user's infrastructure and risk tolerance.

While CVSS version 4.0 was formally introduced in November 2023, version 3.1 remains widely embedded across industry-standard scanning engines, security advisories, vulnerability management databases, and regulatory compliance frameworks. Understanding the mechanics of CVSS v3.1 requires analyzing its metric definitions, its mathematical equations, its custom ceiling rounding function, and the structural dynamics introduced by the concept of authorization scope.

History and Standardization

The earliest version of CVSS, version 1.0, was published in February 2005 by the National Infrastructure Advisory Council (NIAC). It was designed to address the problem of proprietary and inconsistent scoring mechanisms used by commercial security vendors. Prior to CVSS, vendors used subjective, incompatible definitions of severity levels like "Critical" or "Moderate," making it difficult for system administrators to compare vulnerabilities reported by different sources.

Custodianship of CVSS was transferred to FIRST in April 2005 to ensure continued development by a neutral, international, non-profit consortium of incident response teams. FIRST established the CVSS Special Interest Group (SIG) to oversee modifications and refinements to the specification. CVSS version 2.0 was launched in June 2007, gaining widespread adoption when the United States National Vulnerability Database (NVD), operated by the National Institute of Standards and Technology (NIST), adopted it as the default scoring methodology for Common Vulnerabilities and Exposures (CVE) records.

Despite its success, CVSS v2 suffered from architectural limitations. It lacked a mechanism to account for attacks crossing security boundaries, such as a sandbox escape or a virtual machine breakout. It also overemphasized certain types of network access while failing to separate privileges needed to mount an attack from user interaction. To correct these deficiencies, the CVSS SIG released CVSS version 3.0 in June 2015. Version 3.0 introduced the Scope metric, split privileges from interactions, and refined the Attack Vector and Attack Complexity calculations.

In June 2019, FIRST published CVSS version 3.1. Version 3.1 did not introduce new metrics or alter the existing mathematical formulas of version 3.0. Instead, it was an errata and clarification update intended to improve scoring accuracy and consistency among human analysts. It clarified the definitions of Attack Complexity, Privileges Required, and Scope, added a comprehensive User Guide, and standardized the official algorithm used to round fractional numbers.

The Metric Group Architecture

CVSS v3.1 divides all assessment metrics into three hierarchical layers. In standard practice, national databases and software vendors publish Base scores, while consuming organizations are intended to supply Temporal and Environmental adjustments based on their operational context.

• Base Metric Group: Represents the intrinsic qualities of a vulnerability that exist irrespective of time or environment. It includes two sub-categories of metrics: Exploitability (which measures the ease and conditions of exploit execution) and Impact (which measures the direct consequences of successful execution). It also includes the Scope metric, which determines whether the vulnerability affects components beyond its immediate security authority.
• Temporal Metric Group: Represents characteristics that change over time as an issue matures within the security ecosystem. These metrics account for the public availability of exploit code, the existence of remediation methods (such as hotfixes or workarounds), and the degree of confidence in the technical report itself.
• Environmental Metric Group: Represents characteristics specific to a particular organization's infrastructure. It allows an analyst to modify the Base metrics to reflect local mitigation controls, network isolation, or specific business priorities assigned to Confidentiality, Integrity, and Availability.

Base Metric Group Components

The Base Metric Group is composed of eight discrete metrics. Four of these evaluate Exploitability, three evaluate Impact, and one evaluates Scope.

Exploitability Metrics

Exploitability metrics describe the technical prerequisites that must be satisfied for an attacker to successfully execute an exploit against the vulnerable component.

• Attack Vector (AV): Reflects the context by which vulnerability exploitation is possible.
  • Network (N): The vulnerable component is bound to the network stack and can be exploited remotely across multiple network hops (such as the Internet).
  • Adjacent (A): The exploit must be launched from the same shared physical or logical network, such as the same local subnet, Bluetooth range, or IEEE 802.11 wireless network.
  • Local (L): The attacker must have local keyboard access, interactive shell access, or rely on a user opening a malicious file locally.
  • Physical (P): The attacker must physically interact with the target hardware or peripheral equipment (e.g., via a malicious USB stick or hardware debugging port).
• Attack Complexity (AC): Describes the conditions beyond the attacker's direct control that must exist for exploitation to succeed.
  • Low (L): Specialized access conditions or extenuating circumstances do not exist. An attacker can repeatedly and reliably exploit the vulnerability.
  • High (H): Exploitation depends on conditions outside the attacker's control, such as winning a race condition under heavy load, overcoming non-standard address layout randomization (ASLR) without an information leak, or intercepting traffic via a man-in-the-middle position.
• Privileges Required (PR): Quantifies the level of authentication and authorization an attacker must possess prior to launching the exploit.
  • None (N): The attacker requires no prior authentication or access to settings on the target system.
  • Low (L): The attacker requires basic user privileges that provide access to standard files or functions.
  • High (H): The attacker requires administrative, root, or system-level privileges that provide broad configuration control.
• User Interaction (UI): Captures the requirement for a human other than the attacker to participate in the exploitation process.
  • None (N): The vulnerability can be exploited without any human intervention (zero-click execution).
  • Required (R): Successful exploitation requires a separate user to perform an action, such as clicking a malicious link, downloading a file, or accepting an authentication prompt.

The Scope Metric

The Scope (S) metric was a fundamental design addition in CVSS v3.x. In CVSS terminology, an authorization authority is a computing environment (such as an operating system kernel, a database management system, or a hypervisor) that grants and manages access to its own resources.

When a vulnerability exists in one software component (the Vulnerable Component), but compromises resources governed by a completely separate authorization authority (the Impacted Component), a Scope Change occurs.

• Unchanged (U): The vulnerable component and the impacted component share the same security authority, or the impacted component is identical to the vulnerable component. For example, a privilege escalation flaw in the Linux kernel compromises the operating system governed by that same kernel.
• Changed (C): The vulnerable component breaches its own security boundaries and impacts resources managed by a different authority. Examples include cross-site scripting (where a flaw in a web server leads to code execution within the security authority of the client browser) or a virtual machine breakout (where code running in a guest operating system escapes to compromise the hypervisor or host OS).

Impact Metrics

The Impact metrics evaluate the direct technical consequences of a successful exploit against the three core pillars of information security: Confidentiality, Integrity, and Availability. Each metric is evaluated on a three-tier qualitative scale: None, Low, or High.

• Confidentiality Impact (C): Measures the degree of unauthorized information disclosure.
  • None (N): There is no loss of confidentiality.
  • Low (L): Some restricted information is disclosed, but the attacker does not have control over what information is obtained, or the scope of the disclosed data is constrained.
  • High (H): There is total or near-total disclosure of critical information, such as system memory dumps, encryption private keys, or entire administrative credential databases.
• Integrity Impact (I): Measures the degree of unauthorized modification or tampering with system state and data.
  • None (N): There is no loss of integrity.
  • Low (L): Modification of data is possible, but the attacker cannot modify critical system files, or the impact is restricted in scope.
  • High (H): The attacker can modify any data managed by the system, completely alter configurations, or bypass authentication controls entirely.
• Availability Impact (A): Measures the disruption to the accessibility and operation of the vulnerable service or resource.
  • None (N): There is no impact to system availability.
  • Low (L): Performance is degraded or temporary interruptions occur, but the system remains operational without catastrophic outage.
  • High (H): The attacker can cause a sustained, complete denial of service, rendering the component fully inaccessible, offline, or permanently crashed.

The Vector String

A CVSS v3.1 score is formally represented as an alphanumeric vector string. This string compresses the metric choices into an unambiguous, standardized shorthand separated by forward slashes. The string begins with an explicit version prefix: CVSS:3.1.

The standard format for a Base score vector string follows a fixed sequence:

CVSS:3.1/AV:[N,A,L,P]/AC:[L,H]/PR:[N,L,H]/UI:[N,R]/S:[U,C]/C:[N,L,H]/I:[N,L,H]/A:[N,L,H]

For example, a flaw that allows remote, unauthenticated code execution without user interaction, confined to the local operating system, with complete system compromise is encoded as:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Temporal and Environmental metrics may be appended to the vector string when they are defined. If a metric is omitted from the string or marked with an X, it defaults to the "Not Defined" value.

Mathematical Mechanics of the Base Score

Calculating a CVSS v3.1 Base score requires evaluating intermediate sub-scores through algebraic functions, applying numerical weighting constants, and rounding the final output using a custom ceiling function.

Numerical Weighting Constants

The qualitative levels of each metric map to fixed floating-point numbers established by the FIRST CVSS Special Interest Group.

Metric	Qualitative Level	Abbreviation	Numerical Constant
Attack Vector (AV)	Network	N	0.85
	Adjacent	A	0.62
	Local	L	0.55
	Physical	P	0.20
Attack Complexity (AC)	Low	L	0.77
	High	H	0.44
Privileges Required (PR) (Scope Unchanged)	None	N	0.85
	Low	L	0.62
	High	H	0.27
Privileges Required (PR) (Scope Changed)	None	N	0.85
	Low	L	0.68
	High	H	0.50
User Interaction (UI)	None	N	0.85
	Required	R	0.62
Confidentiality (C)	None	N	0.00
	Low	L	0.22
	High	H	0.56
Integrity (I)	None	N	0.00
	Low	L	0.22
	High	H	0.56
Availability (A)	None	N	0.00
	Low	L	0.22
	High	H	0.56

Note that the values for Privileges Required depend on whether the Scope is Unchanged or Changed. When Scope changes, the privilege barrier is mathematically discounted (e.g., PR:Low shifts from 0.62 to 0.68, and PR:High shifts from 0.27 to 0.50), reflecting the fact that low privileges inside an application represent a more severe threat if they can be leveraged to escape the application's environment entirely.

The Roundup Function

CVSS v3.1 specifies that intermediate numbers must not be rounded prematurely, but final scores must be rounded up to one decimal place using a strict ceiling function. This prevents fractional score inflation while maintaining uniform reproducibility across software implementations. Standard floating-point math often causes errors when converting binary fractions to base-10 decimals, leading early CVSS v3.0 engines to disagree on scores.

The CVSS v3.1 specification defines the Roundup function as the smallest number, specified to one decimal place, that is greater than or equal to the input value. In formal pseudocode:

function Roundup(input):
    int_input = round(input * 100000)
    if (int_input % 10000) == 0:
        return int_input / 100000.0
    else:
        return (floor(int_input / 10000) + 1) / 10.0

Under this rule, Roundup(4.000) yields 4.0, whereas Roundup(4.001) rounds strictly upward to 4.1.

Step-by-Step Base Score Formulas

The calculation is executed in three successive stages: the Impact Sub-Score (ISS), the Impact score, and the Exploitability score.

Stage 1: Impact Sub-Score (ISS)

The Impact Sub-Score models the joint probability that at least one of the primary security attributes is compromised. It is derived using the product of the inverse impact weights:

ISS = 1 - [ (1 - Confidentiality) * (1 - Integrity) * (1 - Availability) ]

Stage 2: Final Impact Score

The Impact score depends directly on whether Scope is Unchanged or Changed:

• If Scope is Unchanged:

  Impact = 6.42 * ISS

• If Scope is Changed:

  Impact = 7.52 * (ISS - 0.029) - 3.25 * (ISS - 0.02)^15

Stage 3: Exploitability Score

The Exploitability sub-score is calculated by multiplying the four exploitability metrics by a static scaling constant of 8.22:

Exploitability = 8.22 * AttackVector * AttackComplexity * PrivilegesRequired * UserInteraction

Stage 4: Combining Sub-Scores into the Base Score

If the final Impact score is less than or equal to zero (which occurs only if C, I, and A are all set to None), the overall Base score is defined as 0.0.

Otherwise, the Base score is calculated using one of two formulas based on Scope:

• If Scope is Unchanged:

  BaseScore = Roundup( min( (Impact + Exploitability), 10.0 ) )

• If Scope is Changed:

  BaseScore = Roundup( min( 1.08 * (Impact + Exploitability), 10.0 ) )

Temporal and Environmental Mechanics

The Base score produces a static rating. To provide a complete and contextualized assessment, the CVSS standard introduces the Temporal and Environmental metric groups.

Temporal Metrics and Multipliers

The Temporal score modifies the Base score downward. It accounts for external factors that change over time, such as whether a functional exploit is publicly accessible or an official patch has been published.

Temporal Metric	Qualitative Level	Key	Multiplier
Exploit Code Maturity (E)	Not Defined	X	1.00
	High	H	1.00
	Functional	F	0.97
	Proof-of-Concept	P	0.94
	Unproven	U	0.91
Remediation Level (RL)	Not Defined	X	1.00
	Unavailable	U	1.00
	Workaround	W	0.97
	Temporary Fix	T	0.96
	Official Fix	O	0.95
Report Confidence (RC)	Not Defined	X	1.00
	Confirmed	C	1.00
	Reasonable	R	0.96
	Unknown	U	0.92

The Temporal Score formula multiplies the Base score by these three coefficients and applies the Roundup function:

TemporalScore = Roundup( BaseScore * ExploitCodeMaturity * RemediationLevel * ReportConfidence )

Environmental Metrics and Modified Bases

Environmental metrics permit an organization to customize the score to its operational reality. They operate across two distinct axes:

1. Security Requirements: Multipliers that weight Confidentiality Requirement (CR), Integrity Requirement (IR), and Availability Requirement (AR). The possible values are High (1.5), Medium (1.0), Low (0.5), or Not Defined (1.0).
2. Modified Base Metrics: An analyst can override any of the original Base metrics (yielding MAV, MAC, MPR, MUI, MS, MC, MI, and MA). For instance, if an intrinsically network-accessible service is placed behind a strict firewall on an isolated VLAN, an organization can set Modified Attack Vector (MAV) to Adjacent or Local.

To calculate the Environmental score, a Modified Impact Sub-Score (MISS) is determined first:

MISS = min( 1 - [ (1 - CR * MC) * (1 - IR * MI) * (1 - AR * MA) ], 0.915 )

A Modified Impact score is then calculated from MISS using the Modified Scope (MS) parameter. Next, a Modified Exploitability score is computed using the modified exploitability values. Finally, these sub-scores are passed through the base aggregation equation, multiplied by the Temporal multipliers, and rounded up. The result gives an enterprise-tailored severity score.

Qualitative Severity Ratings

To provide clear communication for non-technical stakeholders, FIRST established a qualitative rating scale. This scale maps specific numerical ranges to standardized textual descriptors.

Qualitative Severity Band	Numerical Base Score Range
None	0.0
Low	0.1 – 3.9
Medium	4.0 – 6.9
High	7.0 – 8.9
Critical	9.0 – 10.0

Worked Calculations

Evaluating standard threat profiles illustrates how the individual formulas interact to produce final scores.

Case Study 1: The Canonical 9.8 Score (Remote Code Execution)

Consider an unauthenticated, zero-click, remote code execution (RCE) vulnerability in an enterprise server daemon (such as the Apache Log4j vulnerability, CVE-2021-44228). The vector string is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The mechanical evaluation proceeds through the formula stages as follows:

1. Metric Lookup:
   • Attack Vector (AV): Network = 0.85
   • Attack Complexity (AC): Low = 0.77
   • Privileges Required (PR): None = 0.85
   • User Interaction (UI): None = 0.85
   • Scope (S): Unchanged
   • Confidentiality (C): High = 0.56
   • Integrity (I): High = 0.56
   • Availability (A): High = 0.56
2. Impact Sub-Score (ISS):

   ISS = 1 - [ (1 - 0.56) * (1 - 0.56) * (1 - 0.56) ]
   ISS = 1 - [ 0.44 * 0.44 * 0.44 ]
   ISS = 1 - 0.085184 = 0.914816

3. Impact Score: Because Scope is Unchanged, the multiplier 6.42 is applied:

   Impact = 6.42 * 0.914816 = 5.87311872

4. Exploitability Score:

   Exploitability = 8.22 * 0.85 * 0.77 * 0.85 * 0.85
   Exploitability = 8.22 * 0.47313625 = 3.889180

5. Base Score Calculation:

   RawScore = Impact + Exploitability
   RawScore = 5.873119 + 3.889180 = 9.762299
   BaseScore = Roundup( min( 9.762299, 10.0 ) ) = 9.8

The vector string produces a score of 9.8. This is the maximum mathematical score possible under CVSS v3.1 when the Scope remains Unchanged. The flaw is rated Critical.

Case Study 2: The Perfect 10.0 Score (Hypervisor Escape)

Now consider a scenario identical in every exploitability and impact metric, but involving a hypervisor escape where an attacker breaks out of a guest virtual machine to compromise the underlying host operating system:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

1. Metric Changes: Scope is Changed (S:C). Privileges Required (PR) remains 0.85 because PR:None is identical under both scopes.
2. Impact Sub-Score (ISS): Identical to Case 1: 0.914816.
3. Impact Score (Scope Changed Formula):

   Impact = 7.52 * (ISS - 0.029) - 3.25 * (ISS - 0.02)^15
   Impact = 7.52 * (0.914816 - 0.029) - 3.25 * (0.914816 - 0.02)^15
   Impact = 7.52 * (0.885816) - 3.25 * (0.894816)^15
   Impact = 6.661336 - 3.25 * (0.187467)
   Impact = 6.661336 - 0.609268 = 6.052068

4. Exploitability Score: Identical to Case 1: 3.889180.
5. Base Score Calculation: Because Scope is Changed, the 1.08 scaling factor is applied:

   RawScore = 1.08 * (Impact + Exploitability)
   RawScore = 1.08 * (6.052068 + 3.889180)
   RawScore = 1.08 * 9.941248 = 10.736548
   BaseScore = Roundup( min( 10.736548, 10.0 ) ) = 10.0

The Scope Change elevates the base sum beyond 10.0, which is capped at 10.0 by the min() function, resulting in a maximum 10.0 Critical rating.

Case Study 3: Reflected Cross-Site Scripting (XSS)

A classic reflected cross-site scripting flaw in a web portal requires an authenticated user to click a specially crafted link. The script executes within the victim's browser rather than on the server itself, triggering a Scope Change. Its vector string is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

1. Constants: AV:N (0.85), AC:L (0.77), PR:N (0.85), UI:R (0.62), S:C, C:L (0.22), I:L (0.22), A:N (0.0).
2. Impact Sub-Score (ISS):

   ISS = 1 - [ (1 - 0.22) * (1 - 0.22) * (1 - 0.0) ]
   ISS = 1 - [ 0.78 * 0.78 * 1.0 ]
   ISS = 1 - 0.6084 = 0.3916

3. Impact Score (Scope Changed):

   Impact = 7.52 * (0.3916 - 0.029) - 3.25 * (0.3916 - 0.02)^15
   Impact = 7.52 * 0.3626 - 3.25 * (0.3716)^15
   Impact = 2.726752 - 3.25 * (0.000000067) ≈ 2.726752

4. Exploitability Score:

   Exploitability = 8.22 * 0.85 * 0.77 * 0.85 * 0.62 = 2.83838

5. Base Score:

   RawScore = 1.08 * (2.726752 + 2.83838) = 1.08 * 5.565132 = 6.01034
   BaseScore = Roundup(6.01034) = 6.1

The vulnerability receives a final rating of 6.1 Medium.

Analysis of Specific Edge Cases and Mechanical Anomalies

The mathematical architecture of CVSS v3.1 exhibits several structural behaviors that security analysts must navigate during practical evaluation.

Floating-Point Arithmetic and Implementation Drift

A notable issue encountered by software developers implementing the CVSS v3.1 specification is the representation of floating-point numbers in standard processors under the IEEE 754 standard. Certain decimal fractions cannot be represented exactly in binary floating-point arithmetic.

For example, a calculation that mathematically evaluates to exactly 4.0 may be represented in memory as 4.000000000000000888.... Under a naive implementation of the Roundup function, this value rounds upward to 4.1 instead of remaining 4.0. To solve this, the CVSS v3.1 specification was published with explicit reference implementations in JavaScript and C that use integer multiplication and small epsilon offsets before performing division and modulo operations.

The Discontinuity of Scope Changed Calculations

The mathematical curve used for Impact when Scope is Changed contains an exponential term: - 3.25 * (ISS - 0.02)^15. For small values of ISS (such as minor information leaks where ISS is under 0.4), the term evaluates to an insignificant fraction near zero. However, as ISS approaches 1.0, this subtraction prevents the score from scaling linearly, flattening the curve near the top.

This design choice ensures that single-impact flaws with Scope Changed do not disproportionately dominate scores, while multi-impact flaws (C:H/I:H/A:H) easily saturate the formula and reach the 10.0 ceiling.

Limitations and Operational Misconceptions

Despite its universal adoption, the practical application of CVSS v3.1 is subject to regular criticism within the vulnerability management and threat intelligence sectors.

Severity versus Risk

The most frequent error in operational cybersecurity is treating CVSS Base scores as a direct representation of business risk. CVSS Base metrics measure technical severity—the theoretical damage potential of a software defect in isolation. They do not measure the likelihood of exploitation, the presence of active adversary campaigns in the wild, or the business criticality of the asset running the vulnerable code.

An unauthenticated remote code execution flaw in an obscure, non-networked diagnostic utility receives the exact same 9.8 CVSS Base score as an RCE flaw in an Internet-facing edge firewall. Remediating vulnerabilities based entirely on high CVSS Base scores causes security operations centers (SOCs) to expend resources patching harmless or unreachable systems while ignoring lower-scored vulnerabilities that are actively being leveraged by ransomware operators.

Integration with EPSS and KEV

To compensate for the gap between technical severity and exploitation likelihood, modern security programs combine CVSS v3.1 with complementary frameworks:

• Exploit Prediction Scoring System (EPSS): Maintained by FIRST, EPSS uses machine learning and global threat telemetry to estimate the empirical probability (from 0% to 100%) that a software vulnerability will be exploited in the wild within the next 30 days. While CVSS indicates how severe the flaw is if exploited, EPSS indicates how likely an attack is to occur.
• CISA Known Exploited Vulnerabilities (KEV) Catalog: Published by the United States Cybersecurity and Infrastructure Security Agency, KEV maintains an authoritative list of vulnerabilities confirmed to be actively weaponized by adversaries in the wild, regardless of their CVSS score.

Metric Ambiguities

In CVSS v3.1, the Attack Complexity (AC) metric is frequently misapplied. Analysts often mark AC as "High" if writing the exploit requires deep reverse-engineering expertise or sophisticated programming skills. However, the CVSS v3.1 specification explicitly dictates that complexity reflects preconditions outside the attacker's control (such as configuration dependencies, race conditions, or required network positioning), not the technical skill or effort needed to author the attack script.

Evolution to CVSS v4.0

In November 2023, FIRST released CVSS version 4.0 to resolve systemic issues identified in version 3.1. CVSS v4.0 introduced substantial architectural shifts:

• Nomenclature Redesign: Version 4.0 introduced new nomenclature to deter organizations from using the Base score alone as a proxy for risk. Scores are explicitly designated as CVSS-B (Base metrics only), CVSS-BT (Base + Threat metrics), CVSS-BE (Base + Environmental metrics), or CVSS-BTE (Base + Threat + Environmental metrics).
• Deprecation of the Scope Metric: The Scope metric was removed due to consistent inconsistency in real-world analyst scoring. It was replaced by explicitly split Impact metrics: Vulnerable System Impact (VC, VI, VA) versus Subsequent System Impact (SC, SI, SA).
• Attack Complexity Refinement: Version 4.0 introduced an Attack Requirements (AT) metric to capture deployment conditions (like non-standard configurations), reserving Attack Complexity strictly for evasion techniques and dynamic defenses.
• Expanded Threat Metrics: The Temporal group was restructured into the Threat Metric group, streamlining the historical tracking of exploit maturity through empirical threat feeds.

Because enterprise vulnerability scanners, national security advisories, and procurement policies evolve over multi-year cycles, CVSS v3.1 remains an essential standard for security assessment and engineering practice.

See also

• Common Vulnerabilities and Exposures (CVE)
• Common Weakness Enumeration (CWE)
• Exploit Prediction Scoring System (EPSS)
• Forum of Incident Response and Security Teams (FIRST)
• National Vulnerability Database (NVD)
• Vulnerability management