Vulnerability management

The Equifax story is, underneath everything, a story about a queue. Every security team runs one: scanners, penetration tests and researcher reports feed findings in faster than engineers can fix them, so something has to decide what is fixed first. The shared language that decision starts from is CVSS (Common Vulnerability Scoring System), published by FIRST and at version 4.0 since November 2023. A CVSS score expresses how severe a vulnerability would be if exploited, from 0.0 to 10.0, with the 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).

Version 4.0 exists partly to correct how its predecessor was misused. Under v3.1 the Base Score, a measure of intrinsic severity, was routinely read as a measure of risk, and whole patching programmes were sorted by it. The 4.0 specification answers with explicit nomenclature: a bare base score is labelled CVSS-B; enriched with threat data it becomes CVSS-BT; enriched with deployment context it becomes CVSS-BE or CVSS-BTE. The labelling is itself the lesson. A score that ignores whether exploitation is happening, and where the affected system sits, is declared incomplete by its own name.

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.

Worked against the opening story: CVE-2017-5638 received a CVSS v3 Base Score of 10.0, because Privileges Required was None, User Interaction was None, Attack Vector was Network, Attack Complexity was Low, and impact was High across all three CIA dimensions. The Environmental picture made it worse rather than better: the affected system was internet-facing and held personal data on millions of consumers, so both the Base and adjusted scores sat at the maximum.

What no base score can say is whether anyone is exploiting the vulnerability this week. CVE-2017-5638 earned its 10.0 on the day it was published, but Equifax's scanner will have carried hundreds of other high-scoring findings beside it. Telling the one under live attack apart from the many that merely look dangerous is a question about likelihood, not severity, and it needs different data. Two signals supply it.

The predictive signal is EPSS (Exploit Prediction Scoring System), maintained by FIRST and at version 4 since March 2025. It is a machine learning model that estimates the probability a specific CVE will be exploited in the wild within the next 30 days, drawing on a large feature set: 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. The two come apart in practice: a vulnerability can carry a high base score and still attract almost no exploitation activity, while a medium-scoring one under active attack carries a high EPSS probability. Read the current EPSS score for a specific CVE from the EPSS data itself rather than inferring it from severity. Combining the two 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.

Prediction is one thing; confirmation is stronger. The CISA KEV (Known Exploited Vulnerabilities) catalogue, introduced November 2021, lists CVEs with confirmed evidence-based active exploitation. BOD 26-04, published in June 2026, superseded the previous KEV directive and now governs risk-based security update prioritisation for US federal civilian agencies. Commercial organisations should treat KEV as a confirmed exploitation signal and set deadlines by exposure, asset criticality, exploitability, compensating controls, and operational risk. Log4Shell (CVE-2021-44228) remains the reference case for why a KEV entry should override ordinary backlog order.

That gives a triage rule a team can defend line by line: KEV first, then EPSS-weighted, CVSS as severity context only. A finding on the KEV catalogue is being exploited now, so it leads the queue whatever its base score. Among everything else, EPSS orders the work by the probability of exploitation, and CVSS tells you how serious it would be if that probability is realised. Queuing by CVSS alone fails for a concrete reason: a meaningful share of exploited CVEs carry only medium base scores, so sorting by severity buries genuinely dangerous, actively exploited findings beneath theoretically severe ones that nobody is touching.

Reading several signals together, rather than trusting one, stopped being optional during 2024. The US National Vulnerability Database fell badly behind on enriching newly published CVEs with the metadata that scoring depends on, and the backlog ran through 2024 and into 2025. Teams that had built their whole prioritisation on that single feed found it stalling underneath them. The lesson mature programmes took was to treat KEV, EPSS and CVSS as independent inputs, so a gap in any one of them degrades the decision rather than halting it.

A score is not always a decision. When the same EPSS or CVSS number could justify either patching tonight or waiting a fortnight, it has described the vulnerability without settling your response to it. SSVC (Stakeholder-Specific Vulnerability Categorization), developed at Carnegie Mellon University and used by CISA, is the structured alternative: instead of a number it walks the triager down a decision tree of plain questions, is the vulnerability being exploited, is the exposure automatable, what is the mission impact, and lands on an explicit action such as Track, Attend or Act. Where a queue has to be auditable and defensible to a regulator, a decision tree that records why each finding was actioned is easier to stand behind than a threshold on a score. The figure below assembles all three signals into the working prioritisation grid, and the knowledge check that follows asks you to run a five-CVE queue through it.

Scoring answers the ordering question, and only that. It does not close a single finding. Closure is the work of a lifecycle: a repeatable path every finding follows from the moment a scanner first sees it to the moment a re-scan proves it gone. Six phases cover the full journey:

1. Discovery: authenticated network scans (Tenable, Qualys, Rapid7), SBOM-driven CVE matching against the software inventory you met in the previous module, SAST findings, and continuous monitoring.
2. Triage: apply CVSS/EPSS/KEV scoring; confirm the finding is not a false positive; identify the asset owner and exposure surface.
3. Prioritisation: assign a severity tier and SLA using the risk-based matrix.
4. Remediation: patch, mitigate (WAF rule, configuration change), or accept risk with documented sign-off from a named owner.
5. Verification: re-scan after remediation using authenticated scanning to confirm the finding is genuinely closed.
6. Post-closure: update SBOM and asset inventory; track mean time to remediate (MTTR) by severity tier against defined SLAs.

Two details decide whether discovery is real or theatrical. The first is the asset inventory: a scanner only scores what it is pointed at, so every server nobody registered is a finding nobody will ever triage. The second is credentials. An unauthenticated scan views a system from outside and guesses versions from network banners; an authenticated scan logs in and reads the installed packages directly, which finds far more and misreports far less. Equifax illustrates how quietly this layer fails: the appliance that decrypted and inspected the company's outbound traffic had been running with an expired certificate, so for months it inspected nothing. When the certificate was finally renewed in late July 2017, the suspicious transfers became visible almost at once and the incident was declared. A blind sensor does not report that it is blind; only deliberate coverage checks reveal it.

The SLA is where the lifecycle acquires teeth. Recommended patch management SLAs: Critical with a 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. An SLA without a named owner and an escalation path is a hope, not a control; the Equifax alert dissolved in exactly that gap between notification and obligation.

The loop in the figure below closes back on itself because new CVEs never stop arriving. Running it against a live production estate raises the questions the final section takes up: what to do when the patch is itself a risk, what to do when a patch cannot be applied at all, and how to measure whether the programme is winning.

Patch advice is easy to give and expensive to follow, because a patch is a change to a live system and changes break things. The organisations that had not applied Microsoft's MS17-010 fix by May 2017 were not all idle; many were weighing the risk of disrupting systems they depended on. WannaCry then encrypted their estates two months after the fix shipped, which is the permanent case for urgency. The case for care arrived on 19 July 2024, when a faulty CrowdStrike content update, pushed to every machine at once, crashed around 8.5 million Windows devices and halted airlines, hospitals and broadcasters that had suffered no attack at all. A deployment mechanism with no staging turned one bad file into a global outage.

Mature programmes hold both lessons at once by deploying in rings. A patch lands first on a small canary group chosen to represent the wider estate, then on progressively larger rings as it proves stable, with rollback rehearsed before the first ring rather than improvised after the last. The ring schedule is not fixed: it compresses with the risk. A routine Medium finding can take a fortnight to cross the rings; a KEV entry on an internet-facing service crosses them in hours, because the 48-hour SLA from the previous section allows nothing slower. The schedule flexes, the sequence does not.

When a patch cannot be applied inside its SLA at all, the programme needs named alternatives rather than silence. The first is mitigation: a compensating control that blocks the exploit path while the vulnerability remains, such as a web application firewall rule matching the exploit pattern, network segmentation that removes the route to the vulnerable service, or disabling the vulnerable feature outright. Mitigation buys time; it does not close the finding, which stays open and tracked. The second is formal risk acceptance: a named owner signs that the organisation will carry this specific risk, within its stated risk appetite, until an expiry date forces the decision to be retaken. The third, often forgotten, is retirement: some systems are cheaper to decommission than to keep defending. What no programme can afford is the unnamed fourth option, deferral by silence, where a finding ages in a backlog with no owner and no decision. That is precisely the state CVE-2017-5638 sat in at Equifax between March and May 2017.

Finally, the programme has to prove it is working, and the obvious number lies. The raw count of open findings rises whenever discovery improves, so a team that deploys better authenticated scanning looks worse on the day it starts seeing clearly. The metrics that reflect risk are ratios and clocks: mean time to remediate by severity tier, measured against the published SLA; the percentage of findings closed inside their SLA; scan coverage, meaning the share of the asset inventory actually scanned with credentials in the last cycle; and the age of the oldest open Critical and of every open KEV finding. Reported as trends, these let a board ask the question that matters: not how many vulnerabilities exist, but how quickly the ones attackers are using get closed.

Sometimes the race is lost anyway. A vulnerability is exploited on day two of a seven-day SLA, and the queue stops being the story. Turning a missed patch into a detected and contained incident, rather than a 76-day exfiltration, is the work of detection and incident response, which the next module takes up. Before that, the challenge and practice tools below let you run the full lifecycle yourself.