CVSS, EPSS and KEV: Cutting 61,000 Findings Down to This Week's Work

Every vulnerability program eventually produces a number nobody can act on. Sixty-one thousand findings, a scanner that adds three thousand a week, and a team of four. The exam knows this, which is why Domain 2 of CySA+ CS0-004 spends far more time on prioritization than on scanning. The skill being tested is not reading a scan report. It is defending a decision about what you are not going to fix.

Severity is not priority

The most common failure in a real program, and the misconception CS0-004 attacks hardest, is treating the CVSS base score as a work queue. Sort descending, start at the top, work down. It feels rigorous and it is close to random, for a reason that is easy to state: the base score describes the vulnerability, not your exposure to it.

A critical scoring flaw in a library that your application never loads, on a host with no network path to anything, is not urgent. A medium scoring flaw with a public exploit, on an internet facing box that holds patient records, is this afternoon's problem. Any prioritization scheme that cannot tell those two apart is producing motion rather than risk reduction.

So priority is a function of three things the score alone does not carry: whether the thing is being exploited, whether it is reachable, and what it would reach.

What CVSS actually measures

CVSS is a severity framework, and it is more capable than the way most teams use it. It is built from metric groups, and almost every organization uses only the first one.

The base group splits into exploitability metrics, which describe how hard the attack is, and impact metrics, which describe what it costs. Attack vector is the one that carries the most weight in practice: network reachable without credentials is a different universe from local access with high privileges. Scope is the metric candidates get wrong most often. Scope changes when exploiting the vulnerability affects resources beyond the vulnerable component, and a hypervisor escape is the canonical example.

The threat group, called temporal in CVSS v3.1, reflects the state of the world: whether a working exploit exists, whether an official fix is available, and how confident the report is. Note the direction. Threat metrics can only reduce the base score or leave it unchanged, because the base score already assumes exploitation is possible.

The environmental group is where your program should be spending its effort. It lets you raise the confidentiality, integrity or availability requirement for an asset that genuinely matters, and it lets you modify the base metrics when your architecture changes the facts. A vulnerability with a network attack vector on a host that is not reachable from any untrusted network can be rescored with a modified attack vector, and that is a defensible, documented downgrade rather than a shrug.

Supplemental metrics arrive with CVSS v4.0 and do not alter the number at all. They carry context, including whether exploitation can cause physical harm, whether the attack is automatable, and how hard recovery would be, and they exist to inform your response rather than the score. Also worth knowing for the exam: v4.0 dropped the confusing v3.1 habit of calling a base-only score "the CVSS score" and introduced explicit CVSS-B, CVSS-BT and CVSS-BTE naming so you can tell which groups were applied.

EPSS answers a different question

CVSS asks how bad it would be. EPSS, the Exploit Prediction Scoring System, asks how likely exploitation actually is. It is a data driven model published by FIRST that outputs, for each CVE, a probability of exploitation activity in the next thirty days, plus a percentile ranking against every other CVE.

The two are not competitors, and the exam is careful about this. They are different axes, and the useful move is to use them together.

The practical effect of EPSS is brutal and useful. The overwhelming majority of published CVEs score below a few percent, so a threshold applied across a backlog removes most of it. Combine it with severity and you get the quadrant that actually drives work: high severity with high probability is drop everything, high severity with low probability is scheduled patching, low severity with high probability deserves a look because attackers clearly find it worthwhile, and low with low is the backlog you accept.

KEV is the list that ends the argument

The CISA Known Exploited Vulnerabilities catalog contains vulnerabilities with reliable evidence of active exploitation in the wild. It is not a prediction. It is an observation, and that is what gives it authority in a room.

For US federal civilian agencies, KEV entries carry binding remediation due dates under BOD 22-01. Everyone else should treat it as the strongest available signal, and as the fastest way to end a disagreement with a system owner who does not want a maintenance window. "This is being exploited right now, and here is the government catalog entry that says so" is a materially different conversation from "the scanner says 9.8."

A funnel that survives a real queue

Put the pieces together and the sixty-one thousand becomes tractable. Not because anything was ignored, but because the sequence puts the cheap, high signal filters first.

Two stages of that funnel deserve care. Validation is not optional: scanners produce false positives, and remediating a finding that was never real burns the same change window as a real one while teaching system owners to ignore you. Manual verification, correlating a second tool, and reading the actual evidence are all Domain 2 expectations. And the context stage is only as good as your asset inventory, which is why objective 2.1 opens on inventory rather than scanners. Unknown assets cannot be scanned, and a coverage percentage without a trustworthy denominator is a number that means nothing.

When you cannot patch

Prioritization produces a list, and part of that list will not be patchable this quarter. Legacy systems with no vendor fix, medical or industrial devices under certification, applications whose vendor has gone quiet. CS0-004 expects you to name what you do instead: compensating controls that reduce exploitability without changing the underlying flaw. Network segmentation to remove the attack path, virtual patching at a WAF or IPS, tightening privileges so exploitation gains less, hardening the configuration, and increasing monitoring on the specific behavior an exploit would produce.

None of those close the vulnerability, and the reporting has to say so. A finding mitigated by a compensating control stays open with documented residual risk, an owner, and a review date. A finding closed because someone put a firewall rule in front of it is how programs quietly accumulate the exposure that shows up in an incident report eighteen months later.

Vulnerability Management is the second largest domain on CySA+ CS0-004 at 26%, covering scan selection, reading tool output critically, prioritization and the control and risk vocabulary that makes a program defensible. It sits directly downstream of SOC alert triage and shares its judgment problem, expands on the generic vulnerability management lifecycle, and feeds the incident response process when a finding turns out to have been exploited already. Work all 26 topics across the four objectives with our CySA+ Domain 2 study guide.

#CySA #CS0004 #VulnerabilityManagement #CVSS #EPSS #KEV #RiskPrioritization #BlueTeam #CompTIA #CyberSecurity