Prioritization: CVSS, EPSS and KEV

A typical enterprise scan returns thousands of findings. You cannot fix them all at once, so prioritization decides which to remediate first. Get it right and you cut real risk quickly; get it wrong and you burn effort on theoretical issues while exploited bugs stay open.

Three data sources anchor modern prioritization: CVSS, EPSS, and KEV.

The Common Vulnerability Scoring System (CVSS) rates the intrinsic severity of a vulnerability on a 0.0 to 10.0 scale. It considers attack vector, complexity, privileges required, and the impact on confidentiality, integrity, and availability.

CVSS answers: how bad is this if exploited? It does not tell you how likely exploitation is.

CVSS has three metric groups:

• Base — intrinsic, unchanging characteristics (the score most people quote).
• Temporal — changes over time (exploit maturity, remediation level).
• Environmental — your specific context (asset importance, mitigations).

Most teams only use the Base score and ignore Environmental, which is exactly the context that should adjust priority.

Patching strictly by CVSS overloads teams: a huge share of CVEs score High or Critical, but only a small fraction are ever exploited in the wild.

Prioritizing every 9.8 equally means you may patch a hard-to-reach bug before one being actively used in ransomware campaigns. Severity is necessary but not sufficient.

The Exploit Prediction Scoring System (EPSS) estimates the probability (0 to 1) that a vulnerability will be exploited in the wild in the next 30 days, based on real-world threat data and machine learning.

EPSS answers: how likely is this to actually be attacked soon? A CVE with EPSS 0.92 deserves attention far more urgently than one at 0.001, even at equal CVSS.

EPSS gives two numbers: a probability and a percentile (rank versus all CVEs). A percentile of 0.99 means it is among the most likely-to-be-exploited.

Use EPSS as a threshold filter: for example, escalate anything above a chosen probability, regardless of CVSS. Re-evaluate periodically because EPSS updates daily as the threat landscape shifts.

CISA maintains the Known Exploited Vulnerabilities (KEV) catalog: a list of CVEs with confirmed, observed exploitation in the wild.

If a CVE is on KEV, it is not theoretical, attackers are using it now. KEV is the strongest single signal that remediation is urgent, and US federal agencies are mandated to fix KEV items within set deadlines.

The signals complement each other:

• KEV — confirmed active exploitation (fix now).
• EPSS — predicted near-term exploitation likelihood.
• CVSS — impact if exploited.

A practical rule: anything on KEV is top priority; then sort by high EPSS and high CVSS, weighted by your asset context.

The same CVE carries different real risk depending on the asset. Multiply technical scores by context:

• Is the asset internet-facing or internal-only?
• Does it hold sensitive data or run a critical service?
• Are compensating controls (WAF, segmentation) in place?

This is the CVSS Environmental idea applied programmatically: prioritize exposed crown jewels over isolated test boxes.

A workable scoring model:

• On KEV? → immediate, override everything.
• EPSS above threshold AND internet-facing? → urgent.
• High CVSS but low EPSS and internal? → standard queue.
• Low everything? → batch with routine patching.

Document the model so prioritization is consistent and defensible, not ad hoc.

Pitfalls to avoid:

• Treating CVSS Base as the whole risk picture.
• Ignoring KEV because the CVSS looks moderate (some KEV entries are not 9+).
• Never re-evaluating: EPSS and KEV change, so re-rank regularly.
• Forgetting asset context, which can flip a finding from low to critical.

Confirm what each signal actually measures.

Prioritization blends three signals: CVSS for impact, EPSS for predicted exploitation likelihood, and KEV for confirmed active exploitation. KEV items demand immediate action; otherwise rank by EPSS and CVSS, weighted by asset exposure and value.

Avoid CVSS-only patching, re-rank as data changes, and document the model. Next we turn prioritized findings into completed fixes with patch management and SLAs.