CVSS (Common Vulnerability Scoring System)

1. Overview

Definition: CVSS (Common Vulnerability Scoring System) is an open, standardized vulnerability severity assessment framework maintained by FIRST (Forum of Incident Response and Security Teams). It measures the technical characteristics of a software vulnerability through defined metrics and converts them into a quantitative score from 0.0 to 10.0 and a rating (None, Low, Medium, High, Critical), so that different organizations, products, and countries can compare and communicate the relative risk of a vulnerability on a common scale.

The background to CVSS lies in the absence of a common language for vulnerability information. As vulnerability disclosures surged in the early 2000s, each vendor attached its own ratings such as "urgent," "important," or "moderate," and because severity judgments differed from one supplier to another for the same flaw, consumers (security staff and managers) found it hard to rationally set patch priorities. To resolve this confusion, CVSS v1 was released in 2005 at the proposal of the US NIAC, and FIRST took over its operation, progressing through v2 (2007), v3.0 (2015), and v3.1 (2019) to the release of v4.0 in November 2023.

A second background is the reality that vulnerability management is shifting to a risk-based approach. The CVEs (Common Vulnerabilities and Exposures) disclosed each year number in the tens of thousands, and an organization's patching capacity cannot address them all at once. An objective, repeatable criterion for deciding "what to fix first" was therefore needed, and CVSS serves as the starting point by quantifying vulnerability severity to provide the primary basis for prioritization.

A third background is linkage with regulations and standards. As the US NVD (National Vulnerability Database) assigns a CVSS score to every CVE, and as industry regulations such as PCI-DSS require "remediation of vulnerabilities rated CVSS 4.0 or higher," CVSS has become the de facto common scale for vulnerability management worldwide. Domestically as well, security solutions and vulnerability assessment reports adopt CVSS as their basic metric, making it a standard that must be mastered from a professional-engineer perspective.

2. CVSS Structure — Metric Groups and Scoring

The essence of CVSS is that it evaluates a vulnerability's characteristics in metric groups of differing nature. The reason for separating the groups is that mixing a vulnerability's "intrinsic properties," its "properties that change over time," and its "properties valid only within our organization" would blur the meaning of the score. The conceptual diagram below shows the overall metric structure of CVSS (the common skeleton of v3.1 and v4.0).

flowchart TB
    CVSS["CVSS scoring system(0.0~10.0)"]
    BASE["Base metrics(Base) - intrinsic, immutable traits"]
    TEMP["Threat/Temporal metrics(Threat·Temporal) - change over time"]
    ENV["Environmental metrics(Environmental) - reflect org context"]
    SUPP["Supplemental metrics(Supplemental, v4.0) - informational(no score effect)"]
    CVSS --> BASE
    CVSS --> TEMP
    CVSS --> ENV
    CVSS --> SUPP
    BASE --> EXP["Exploitability(AV·AC·PR·UI, etc.)"]
    BASE --> IMP["Impact(confidentiality·integrity·availability)"]

Base metrics assess the unchanging intrinsic characteristics of the vulnerability itself and form the backbone of the CVSS score. These are further divided into "Exploitability" and "Impact." Exploitability is the axis measuring how easily an attacker can reach the vulnerability, consisting of Attack Vector (AV: Network, Adjacent, Local, Physical), Attack Complexity (AC: Low, High), Privileges Required (PR: None, Low, High), and User Interaction (UI: None, Required). For example, a vulnerability exploitable remotely over the network (AV:N), without special conditions (AC:L), without authentication (PR:N), and without user involvement (UI:N) attains the maximum exploitability score, raising the risk of worm-like self-propagation.

Impact assesses how much confidentiality (C), integrity (I), and availability (A) are each damaged (None, Low, High) when the vulnerability is successfully exploited. The reason for evaluating the three elements separately is that information leakage (confidentiality), data tampering (integrity), and service disruption (availability) inflict damage of entirely different natures on an organization. In v3.1, a Scope concept was added here to reflect whether the damage from the vulnerable component crosses a security authority boundary to affect other components (Changed/Unchanged). For example, if a hypervisor vulnerability lets a guest VM take over the host, Scope becomes Changed and the score rises sharply.

Threat/Temporal metrics adjust for characteristics that change over time. The Temporal group in v3.1 consists of Exploit Code Maturity (E), Remediation Level (RL), and Report Confidence (RC), expressing how the risk differs depending on whether only a PoC exists or a working exploit has been published. v4.0 simplifies this into a Threat metrics group retaining only "Exploit Maturity (E)," because it judged this role to overlap with external threat information such as the EPSS discussed later.

Environmental metrics reflect that even for the same vulnerability, the actual risk in our organization's environment differs. They weight the confidentiality, integrity, and availability importance of the asset (Security Requirements CR, IR, AR) and allow the base metrics to be modified (Modified Base) according to mitigations the organization has already applied. For example, for a DB vulnerability on a closed network not exposed to the internet, the attack vector is effectively limited, so it is reasonable to lower the environmental score.

The score is calculated by combining the Exploitability and Impact sub-scores through a defined formula to yield 0.0 to 10.0, which is then mapped to a rating. The table below shows the severity rating bands common to v3.1/v4.0.

3. Risk-Based Prioritization and EPSS/KEV Linkage

Determining patch order by CVSS score alone has a structural limitation. The CVSS base score measures "how severe it could be (severity)," but it says nothing about "how likely it is to actually be attacked (likelihood)." NVD statistics show that a large share of disclosed CVEs is concentrated in High and Critical, so relying on the base score alone makes everything "full of dangerous items," effectively paralyzing the prioritization function. In fact, research repeatedly reports that only a single-digit percentage of all disclosed vulnerabilities is actually used in attacks.

To fill this gap, modern vulnerability management combines CVSS with EPSS, KEV, and asset context. EPSS (Exploit Prediction Scoring System), also operated by FIRST, uses a machine learning model to predict the probability (0 to 1) that a given vulnerability will actually be exploited within the next 30 days. If CVSS is "the size of the damage," EPSS is the complementary axis of "the likelihood of exploitation." KEV (Known Exploited Vulnerabilities) is a list of vulnerabilities confirmed to be actually exploited, operated by the US CISA; being listed means it is not a "theoretical risk" but an "ongoing threat."

The flowchart below shows the risk-based prioritization process that starts from CVSS and combines EPSS, KEV, and asset context.

flowchart LR
    A["Identify vulnerability(CVE·scanner)"] --> B["Compute CVSS base score(severity)"]
    B --> C["Apply EPSS(exploit probability)"]
    C --> D["Check KEV(actual exploitation)"]
    D --> E["Reflect asset criticality·environmental metrics"]
    E --> F{"Decide risk priority"}
    F -->|"High"| G["Immediate patch·mitigation"]
    F -->|"Low"| H["Fold into periodic patch cycle"]

In practice, policies classify, for example, vulnerabilities "with CVSS 9.0 or higher AND listed in KEV, or with EPSS 0.5 or higher" as immediate-action targets, while other Critical/High ones are handled by SLA-based periodic patching. This way, even among thousands of Criticals, resources can be focused on the dozens that are "dangerous right now," dramatically improving the efficiency of limited security staff.

As a concrete case, Log4Shell (CVE-2021-44228) in 2021 scored 10.0 (Critical) under CVSS v3.1 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H); it enabled remote arbitrary code execution without authentication and its impact spread to other systems (S:C), earning the maximum score, and it was immediately listed in KEV right after disclosure, triggering urgent response worldwide. Conversely, there are many vulnerabilities with high CVSS but low EPSS/KEV, so viewing the three indicators together is the way to avoid both over- and under-response.

4. Version Comparison — v3.1 and v4.0, Similar Systems

CVSS v4.0 was overhauled by squarely accepting the criticisms raised against v3.1. The biggest change is the abolition of the Scope metric; instead of Scope, which was often criticized as ambiguous, it explicitly separates Vulnerable System impact (VC·VI·VA) and Subsequent System impact (SC·SI·SA) to express damage propagation more precisely. It also newly added the Attack Requirements (AT) metric, which considers whether specific conditions are needed for a successful attack, and subdivided User Interaction (UI) into None, Passive, and Active.

The second change is the addition of the Supplemental metrics group. It holds information useful for operational judgment such as Safety, Automatable, Recovery, and Value Density, but as informational indicators that do not affect the score. Third, v4.0 introduced a naming convention to transparently indicate which metrics a score reflects, such as CVSS-B (Base only), CVSS-BT (Base+Threat), CVSS-BE (Base+Environmental), and CVSS-BTE (full). This responds to the long-standing criticism that "most organizations use only the base score and do not leverage the temporal/environmental metrics, so scores are overstated."

CVSS has a role distinct from other security standards such as CVE, CWE, and EPSS. If CVE addresses "which vulnerability it is (identification)" and CWE "what type of flaw it is (classification)," then CVSS handles "how severe it is (assessment)." Also, in supply chain security, several standards link together like a chain: components are identified with [[sbom]], [[vex-vulnerability-exploitability-exchange]] determines "whether that vulnerability actually affects our product," and then CVSS assigns the severity.

5. Deep Dive: Recent Trends and Practical Application

The vulnerability management paradigm has recently shifted from "severity-centric" to "exploitability- and exposure-centric." This results from the widely recognized limitation of using CVSS alone; Gartner and others have recommended that organizations move to risk-based vulnerability management (RBVM) and continuous threat exposure management (CTEM), which integrate CVSS, EPSS, threat intelligence, and asset criticality (the detailed figures and timing vary by report edition, so they should be understood in general terms). Indeed, decision models that classify into act/track/watch via a question-and-answer judgment of "exploitation status, automatability, and mission impact"—rather than lining items up by a single score—are spreading, as with the US government's SSVC (Stakeholder-Specific Vulnerability Categorization).

As a practical application case, large financial firms and cloud providers apply the CVSS base score as a basic filter over scanner results across tens of thousands of assets, and on top of it compute their own weighted risk score combining EPSS probability and KEV listing, operating a patch SLA (e.g., 24 hours for KEV listing, 7 days for Critical, 30 days for High). This escapes the pile of thousands of Criticals produced by CVSS and lets the organization focus on the few that genuinely pose a threat. Also, in the [[devsecops]] pipeline, a CVSS threshold gate (e.g., block the build when 7.0 or higher is found) is applied to dependency-scan results at the build stage, screening out vulnerabilities before they reach production.

From an exam perspective, CVSS links strongly with questions such as "Explain the vulnerability assessment/management system," "Methods for risk-based vulnerability management," and "Limitations of CVSS and remedies (EPSS/KEV linkage)." When composing an answer, an effective flow is to (1) define the concept with the CVSS metric structure (Base, Threat, Environmental), (2) show currency with the improvements in v4.0, (3) point out the limitations of using CVSS alone, and (4) present a practical solution with risk-based prioritization combining EPSS, KEV, and asset context.

6. Considerations and Implications

From a professional-engineer perspective, CVSS should be treated not as "the score itself" but as an input to risk-based decision-making, considering the following comprehensively.

• Application strategy (do not use alone): Setting priorities by the CVSS base score alone leaves one overwhelmed by an excessive pile of Criticals, so establish a risk-based vulnerability management (RBVM) policy combining EPSS (exploit probability), KEV (actual exploitation), and asset criticality, and be sure to reflect environmental metrics suited to the organization's characteristics.
• Trade-off (precision vs. operational cost): Precise evaluation down to temporal/environmental metrics increases the realism of the score but raises the per-asset manual burden. Enterprise-wide precise evaluation is unrealistic, so a tiered approach—deeply evaluating core assets and externally exposed segments first while managing the rest with automated base scores—is realistic.
• Guarding against score inflation/misuse: CVSS is designed assuming the "worst-case scenario," so scores tend to come out high, and distortions occur where vendors deliberately inflate or deflate scores to evade responsibility. Therefore, do not blindly trust NVD/vendor scores; re-evaluate with your own environmental metrics, and confirm which metrics a score reflects, as with the CVSS-BTE notation in v4.0.
• Governance/regulatory alignment: Design the CVSS thresholds required by regulations such as PCI-DSS to align with patch SLAs and [[isms-p]] control items, and record remediation history and rationale (score, EPSS, KEV) to ensure audit traceability.
• Outlook/related technologies: CVSS can systematically handle supply-chain-wide risk when combined with [[sbom]], [[vex-vulnerability-exploitability-exchange]], [[mitre-attack]], and [[threat-modeling]], and going forward, decision-centric models such as SSVC and CTEM combined with AI-based exploit prediction are expected to evolve beyond "score ranking" into context-aware risk management.

References

• FIRST, "CVSS v4.0 Specification Document". https://www.first.org/cvss/v4-0/specification-document
• FIRST, "Common Vulnerability Scoring System SIG". https://www.first.org/cvss/
• FIRST, "EPSS — Exploit Prediction Scoring System". https://www.first.org/epss/
• CISA, "Known Exploited Vulnerabilities Catalog". https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NIST NVD, "Vulnerability Metrics". https://nvd.nist.gov/vuln-metrics/cvss

In one line: CVSS is a standard vulnerability severity assessment system maintained by FIRST that derives a 0.0–10.0 score from Base, Threat, and Environmental metrics; its limitation of measuring only severity must be complemented by risk-based prioritization combining EPSS (exploit probability), KEV (actual exploitation), and asset context to hold practical value.