Vulnerability management
By the end of this module you will be able to:
- Calculate a CVSS 4.0 Base Score and explain the Threat and Environmental metric groups
- Use EPSS scores alongside CVSS to produce a risk-based prioritisation decision
- Apply the CISA KEV catalogue to identify actively exploited vulnerabilities requiring immediate action
- Design a patch management programme with defined SLAs per severity tier
Equifax data breach, March to July 2017
Equifax 2017: patch available, alert sent, 147 million records exfiltrated
In March 2017, the Apache Software Foundation released a patch for CVE-2017-5638, a critical remote code execution vulnerability in the Apache Struts web framework. Equifax, one of the three largest consumer credit bureaux in the United States, was running a vulnerable version of Struts in its online dispute portal. The patch was available. Equifax's vulnerability scanning tool had identified the vulnerability. The alert had been sent. The patch was not applied.
In May 2017, attackers exploited CVE-2017-5638 to gain access to Equifax's network and spent 76 days exfiltrating the personal data of 147 million US citizens, including Social Security numbers, dates of birth, and home addresses. The CVE carried a CVSS v3 Base Score of 10.0: network-exploitable, no authentication required, no user interaction, high impact on confidentiality, integrity, and availability. Equifax paid $700 million in settlements and fines.
The breach was not a discovery failure; it was a prioritisation and escalation failure. Discovery occurred; the process that should have converted a CRITICAL alert into a mandatory remediation timeline with accountability did not exist.
CVSS 4.0: scoring vulnerability severity
CVSS (Common Vulnerability Scoring System) v4.0, published by FIRST in November 2023, provides a framework for communicating the characteristics and severity of software vulnerabilities. Scores range from 0.0 to 10.0; NVD qualitative labels: None (0.0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), Critical (9.0-10.0).
CVSS 4.0 defines four metric groups:
- Base metrics (intrinsic characteristics): Attack Vector (Network/Adjacent/Local/Physical), Attack Complexity (Low/High), Privileges Required (None/Low/High), User Interaction (None/Passive/Active), and Confidentiality/Integrity/Availability impact on both the vulnerable system and subsequent systems.
- Threat metrics (replaces Temporal in v3.1): Exploit Maturity (Attacked/Proof-of-Concept/Unreported/Not Defined). A vulnerability with confirmed active exploitation (Attacked) scores higher than one with only theoretical exploitability.
- Environmental metrics: allow organisations to adjust scores based on deployment context. A vulnerability in an internet-facing system storing PII scores higher than the same vulnerability in an air-gapped internal tool.
- Supplemental metrics (informational, do not affect score): Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency.
CVE-2017-5638 (Equifax) received a CVSS v3 Base Score of 10.0: Privileges Required None, User Interaction None, Attack Vector Network, Attack Complexity Low, and High impact across all three CIA dimensions. Combined with an internet-facing affected system storing PII for millions of consumers, both the Base and Environmental scores were maximum.
With an understanding of cvss 4.0: scoring vulnerability severity in place, the discussion can now turn to epss and cisa kev: prioritisation beyond cvss, which builds directly on these foundations.
EPSS and CISA KEV: prioritisation beyond CVSS
EPSS (Exploit Prediction Scoring System) v3, maintained by FIRST (2023), is a machine learning model that estimates the probability a specific CVE will be exploited in the wild within the next 30 days. It uses over 1,400 features: CVE characteristics, CVSS scores, public exploit availability, social media discussion, and dark web activity. EPSS scores range from 0% to 100%.
CVSS measures severity; EPSS measures likelihood. They are complements, not substitutes. FIRST research found that only approximately 5% of CVEs with a public exploit are actually exploited within 30 days. CVSS Critical CVEs without public exploits have a median EPSS score of approximately 0.3%. CVEs with confirmed exploitation typically score above 50%. Combining them produces a four-quadrant prioritisation:
- CVSS Critical/High + EPSS above 10%: emergency queue, immediate patch.
- CVSS Critical/High + EPSS below 10%: standard SLA remediation.
- CVSS Medium/Low + EPSS above 10%: expedited review; active exploitation warrants escalation.
- CVSS Medium/Low + EPSS below 10%: defer or risk-accept with documented owner sign-off.
The CISA KEV (Known Exploited Vulnerabilities) catalogue, introduced November 2021, lists CVEs with confirmed evidence-based active exploitation. KEV entries carry mandatory remediation deadlines for US federal agencies under CISA BOD 22-01 (typically two weeks for internet-facing systems). Commercial organisations adopt the same deadlines as best-practice SLAs. Log4Shell (CVE-2021-44228) was added to the KEV catalogue on 10 December 2021 with a six-day federal remediation deadline, the fastest CISA had set at the time.
With an understanding of epss and cisa kev: prioritisation beyond cvss in place, the discussion can now turn to vulnerability lifecycle and patch management slas, which builds directly on these foundations.
“Vulnerability management programs must include policies, procedures, and resources to detect, assess, track, and remediate vulnerabilities in a timely manner. The program should prioritize vulnerabilities based on their potential impact to the organization.”
NIST SP 800-40r4, Section 2: Vulnerability Management Fundamentals
“All federal civilian executive branch agencies must remediate every vulnerability listed in the Known Exploited Vulnerabilities catalogue by the due date specified for that vulnerability. The catalogue reflects vulnerabilities that have been actively used by adversaries in real-world attacks.”
CISA Binding Operational Directive (BOD) 22-01, November 2021: Reducing the Significant Risk of Known Exploited Vulnerabilities
Vulnerability lifecycle and patch management SLAs
A vulnerability management programme covers the full lifecycle from discovery to verified closure across six phases:
- Discovery: authenticated network scans (Tenable, Qualys, Rapid7), SBOM-driven CVE matching, SAST findings, and continuous monitoring.
- Triage: apply CVSS/EPSS/KEV scoring; confirm the finding is not a false positive; identify the asset owner and exposure surface.
- Prioritisation: assign a severity tier and SLA using the risk-based matrix.
- Remediation: patch, mitigate (WAF rule, configuration change), or accept risk with documented sign-off from a named owner.
- Verification: re-scan after remediation using authenticated scanning to confirm the finding is genuinely closed.
- Post-closure: update SBOM and asset inventory; track mean time to remediate (MTTR) by severity tier against defined SLAs.
Recommended patch management SLAs: Critical with KEV entry or EPSS above 50%: 48 hours for internet-facing systems, 7 days for internal; Critical without active exploitation: 14 days; High: 30 days; Medium: 90 days; Low: 180 days or risk-accept. All deferred patches beyond their SLA require documented risk acceptance signed by a named owner with an expiry date.
Common misconception
“CVSS Base Scores reflect current exploitation risk, so monitoring CVSS scores alone is sufficient for prioritisation.”
CVSS Base Scores are set at the time of CVE publication and do not change when new exploit code is released, when the vulnerability is added to the CISA KEV catalogue, or when a ransomware group begins actively exploiting it. A CVE published in 2021 with a CVSS 7.5 score may have an EPSS score of 80% today if exploit code was recently released. Review KEV additions daily; re-triage any open findings that appear on the catalogue even if they were previously de-prioritised on CVSS alone.
Common misconception
“Running a monthly vulnerability scan and producing a report constitutes a vulnerability management programme.”
Scanning produces a list of findings; a programme converts those findings into prioritised remediation work with named owners, SLA deadlines, escalation paths, and tracking to verified closure. Organisations that scan without a downstream process accumulate backlogs of thousands of unresolved findings. The Equifax 2017 breach occurred despite active scanning: the process that should have converted the CRITICAL alert into mandatory remediation with accountability did not exist. The metric that distinguishes a programme from a scan is mean time to remediate (MTTR) by severity tier, measured against defined SLAs.
A vulnerability management team has 2,400 open CVEs: 180 CVSS Critical (9.0+), 600 High, and the remainder Medium or Low. Capacity allows approximately 50 remediations per week. The team wants to reduce risk from active exploitation most efficiently. Which prioritisation approach yields the most risk reduction per unit of effort?
Log4Shell (CVE-2021-44228, CVSS 10.0) was published on 9 December 2021 and added to the CISA KEV catalogue the same day. Your authenticated scan identifies three instances of a vulnerable Log4j version in internal developer tooling: a local CI build server, a test results dashboard, and a code coverage report generator. None are internet-facing. Your internet-facing production systems have already been patched. How should you classify and schedule remediation of the internal instances?
Equifax had vulnerability scanning enabled in March 2017. The scan tool identified CVE-2017-5638. The alert was generated. The system remained unpatched when attackers exploited it two months later. Which phase of the vulnerability lifecycle failed, and what process control would most directly have prevented the breach?
A vulnerability has a CVSS 4.0 base score of 6.8 (Medium) but appears in the CISA Known Exploited Vulnerabilities catalogue with an EPSS score of 0.94. How should it be prioritised?
Key takeaways
- CVSS 4.0 measures intrinsic severity across four metric groups: Base (inherent characteristics), Threat (exploitation maturity), Environmental (deployment context), and Supplemental (informational only). The Threat metric group, new in v4.0, explicitly captures confirmed exploitation.
- EPSS predicts exploitation probability within 30 days using machine learning. Combined with CVSS, it produces a risk-based prioritisation that reduces the active remediation queue by approximately 85% while covering nearly all actually exploited vulnerabilities.
- The CISA KEV catalogue confirms active exploitation in the wild. Any KEV entry warrants immediate re-triage regardless of when the CVE was originally scored. Federal SLAs (48 hours to 2 weeks) are a practical baseline for commercial organisations.
- A vulnerability lifecycle runs from discovery through triage, prioritisation, remediation, verification, and post-closure tracking. The Equifax breach was a prioritisation and escalation failure: discovery occurred; the mandatory remediation process did not.
- Patch management SLAs must be documented, assigned to named owners, and tracked. Without enforcement, SLAs become aspirational targets that erode under delivery pressure.
You can now manage vulnerabilities systematically. But despite all preventive controls, incidents will occur. How do you detect an active intrusion and respond effectively under pressure? Module 22 covers detection and incident response.
Standards and sources cited in this module
CVSS v4.0 Specification (FIRST, 2023)
Base, Threat, Environmental, and Supplemental metric groups with scoring formula and worked examples.
CISA KEV Catalogue (BOD 22-01)
Actively exploited vulnerability catalogue with remediation deadlines for US federal agencies and best-practice SLA guidance.
EPSS v3 Model Documentation (FIRST)
Exploit Prediction Scoring System: model features, scoring methodology, and Cyentia Institute research on prioritisation effectiveness.
NIST SP 800-40r4: Guide to Enterprise Patch Management Planning
Patch management policy, SLA definition, and vulnerability lifecycle guidance.
FTC vs Equifax Consent Order and Senate Judiciary Committee Testimony (2017-2018)
Vulnerability management lifecycle failure case study: patch available, alert sent, remediation process missing.