Common Vulnerability Scoring System (CVSS)

CVSS decomposes severity into three distinct metric groups to provide layered context:

• Base Metrics: Intrinsic qualities of a vulnerability that are constant over time and across user environments. This includes Attack Vector (AV) , Attack Complexity (AC) , and Confidentiality/Integrity/Availability (CIA) Impact.
• Temporal Metrics: Characteristics that evolve over the lifecycle of the vulnerability, such as the availability of exploit code (Exploit Code Maturity - E) or an official fix (Remediation Level - RL).
• Environmental Metrics: Customizable modifiers that reflect the specific importance of the affected asset to an organization, allowing analysts to adjust Confidentiality Requirement (CR) and other impact metrics.

The score is derived from a compact text representation known as the CVSS Vector String. This machine-readable string encodes all selected metric values, providing a complete, transparent audit trail of how the score was calculated.

• Example: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• This string explicitly defines the vulnerability as Network exploitable (AV:N) with Low attack complexity (AC:L) and No privileges required (PR:N) , leading to a High impact on all three CIA pillars.
• The vector string enables automated, deterministic parsing by vulnerability scanners and ensures reproducibility across different tools.

To make numerical scores immediately actionable, CVSS maps quantitative ranges to a qualitative severity scale for triage prioritization:

• None: 0.0
• Low: 0.1 - 3.9
• Medium: 4.0 - 6.9
• High: 7.0 - 8.9
• Critical: 9.0 - 10.0 A vulnerability scoring a 9.8 is classified as Critical and typically demands immediate remediation within a 24-hour window, whereas a 5.5 is Medium and can be scheduled into a standard patch cycle.

A pivotal Base Metric, Scope (S) , captures whether a vulnerability in one software component can impact resources beyond its intended security authority.

• Unchanged (S:U) : The vulnerable component and the impacted component are the same, meaning the attack is contained within a single security boundary.
• Changed (S:C) : The vulnerability allows the attacker to escape the component's sandbox and affect a different component, such as breaking out of a virtual machine to access the hypervisor. When Scope is Changed, the impact sub-score is weighted more heavily, reflecting the severity of a privilege escalation or container breakout.

The framework has evolved to address scoring ambiguities and new attack vectors:

• CVSS v3.1: The current industry standard, which introduced the Scope metric and refined the scoring formula to better represent real-world impact.
• CVSS v4.0: The next-generation standard that supplements the Base Score with new supplemental metrics like Automatable (A) , Recovery (R) , and Value Density (V) . It also introduces a Vulnerability Response (VR) metric to signal the urgency of remediation.
• The shift to v4.0 aims to provide finer granularity for OT/ICS environments and safety-critical systems where traditional IT impact metrics are insufficient.

CVSS is maintained and governed by the Forum of Incident Response and Security Teams (FIRST) , ensuring vendor-neutral, community-driven evolution.

• The CVSS Special Interest Group (SIG) manages the standard's development, publishes official documentation, and provides a reference calculator.
• Organizations like the NIST National Vulnerability Database (NVD) act as primary aggregators, enriching CVE records with CVSS Base Scores to provide a consistent baseline for global vulnerability management programs.
• This governance model prevents proprietary scoring inflation and ensures that a Critical rating from one vendor is mathematically equivalent to a Critical rating from another.

An automated process for identifying open-source components in a codebase and cross-referencing them against vulnerability databases. SCA tools ingest NVD feeds and apply CVSS scores to prioritize findings. Modern SCA goes beyond simple version matching to determine reachability analysis—whether the vulnerable function is actually called by the application—refining the effective severity beyond the base score.