A modern enterprise scanner can easily report tens of thousands of findings. No team can patch them all immediately, and trying to do so usually means the most dangerous issues sit in the queue alongside trivial ones. Sensible prioritisation depends on understanding the data behind the headlines — CVE identifiers, CVSS scores, EPSS probabilities, and the CISA KEV catalogue — and combining them with context only you have about your own environment.
CVE: the identifier, not a score
A CVE (Common Vulnerabilities and Exposures) ID is just a unique label assigned by a CVE Numbering Authority (CNA) to a specific vulnerability — for example, CVE-2021-44228 for Log4Shell. The ID lets the whole industry refer to the same issue. Importantly, a CVE itself does not tell you how dangerous something is; it only says "this is a distinct vulnerability that exists". A record will typically include a short description, affected products, references to advisories, and (usually) one or more CVSS scores. When a vendor publishes an advisory, the CVE is the primary key you should use to track it through your scanners, ticketing system, and SBOM queries.
CVSS: technical severity, not risk
CVSS (Common Vulnerability Scoring System) gives a 0.0–10.0 score reflecting the technical characteristics of a vulnerability. It is widely misused as a proxy for risk; it is really a measure of severity in a generic context.
- Base score – Properties of the vulnerability itself: attack vector, complexity, privileges required, user interaction, impact on confidentiality, integrity, and availability. This is the number most people quote.
- Temporal score – Adjusts for exploit maturity, remediation availability, and report confidence over time. Rarely populated consistently in practice.
- Environmental score – Adjusts the base score for your environment (e.g. is the affected system internet-facing, does it process sensitive data). Almost no one bothers to compute this, which is part of the problem.
CVSS v3.1 is still the most common in tooling; CVSS v4.0 improves nuance but is not yet universal. A CVSS 9.8 in a non-internet-facing test environment is very different from the same score on your customer-facing API gateway — the base number is identical.
EPSS: how likely is this to be exploited
EPSS (Exploit Prediction Scoring System), maintained by FIRST, assigns each CVE a probability (0.0–1.0) that it will be exploited in the wild within the next 30 days. It is updated daily and is based on real-world observations: exploit code availability, mentions in threat intel feeds, scanner activity, and historical patterns. The headline insight from EPSS data is that most CVEs — even high-CVSS ones — are never exploited. A relatively small subset accounts for almost all real-world exploitation. Using EPSS as a filter alongside CVSS lets you push the long tail of "scary-looking but never used" issues down the queue and focus on the smaller set with credible probability of being attacked.
KEV: vulnerabilities being exploited right now
CISA's Known Exploited Vulnerabilities (KEV) catalogue is a curated list of CVEs with confirmed evidence of active exploitation. It is conservative by design — only well-evidenced cases go in. A vulnerability appearing on KEV is one of the strongest signals you can get that it should be patched urgently, regardless of CVSS or EPSS. US federal agencies are bound by Binding Operational Directive 22-01 to remediate KEV entries on a fixed schedule; that is a reasonable benchmark for everyone else. A practical rule of thumb: a KEV entry on an internet-facing system is a "drop everything" event. A KEV entry on an internal system is still high priority — most real-world breaches involve at least one KEV exploit somewhere in the kill chain.
Combining the signals in practice
No single score should drive patching alone. A workable model layers them with environmental context.
- Highest priority (patch within days) – Internet-facing systems with a KEV entry, or non-KEV CVEs with very high EPSS (>0.5) on exposed assets.
- High priority (patch within weeks) – Internal systems with KEV entries; high CVSS with moderate EPSS; vulnerabilities on systems handling regulated or sensitive data.
- Standard priority (patch on monthly cycle) – High or critical CVSS with low EPSS, on internal systems with good compensating controls.
- Lowest priority (patch on next major update) – Low CVSS, low EPSS, no exposure, no sensitive data. These still need to be tracked, but they should not crowd out the urgent work.
Add a layer for compensating controls: a WAF rule, EDR detection, network segmentation, or MFA may legitimately lower the urgency of a finding, but the mitigation should be documented and time-bounded. The aim is to produce a short, defensible list of "fix this now" that the whole organisation can rally around, and a longer backlog with realistic deadlines — rather than a sea of "criticals" that everyone learns to ignore.