EPSS score: how to use it for patch prioritization

TL;DR

Use EPSS as a probability: the estimated chance a CVE gets exploited in the wild in the next 30 days. Patch the intersection of high EPSS and real exposure first, not just high CVSS. CVSS says how bad it could be; EPSS says how likely someone tries. Together they beat either alone.

The query

EPSS score: how to use it for patch prioritization

Use this when

• Your scanner shows hundreds of highs and criticals and you can patch dozens
• Leadership asks why you patched CVE-A before CVE-B
• You want a data-driven patch queue instead of severity-sorted panic
• You are tuning SLAs for vulnerability remediation

Not for

• Running the vulnerability scans themselves
• Responding to an active exploitation
• Computing CVSS scores

Steps

1. Get EPSS scores for your open CVEs. The public EPSS data is free; many scanners and asset tools now include the score and percentile. Pull it into the same view as your CVE list.

Expected output: every open CVE has an EPSS probability and percentile next to its CVSS.

1. Sort by EPSS percentile first, then CVSS. A CVE with EPSS 0.9 and CVSS 7 is usually a better use of your week than EPSS 0.01 and CVSS 9.8 on an internal box. Probability of attack beats theoretical severity.

Expected output: a re-ranked queue that looks different from the CVSS-sorted one, and that is the point.

1. Layer in your exposure: internet-facing, authenticated-only, internal. Multiply, informally: high EPSS plus internet-facing goes to the top; high EPSS on an isolated host can wait a cycle.

Expected output: the top of the queue is both likely-exploited and reachable.

1. Check for known exploitation separately: if CISA KEV lists it or you see exploit code in the wild, it jumps the queue regardless of EPSS. EPSS predicts; KEV confirms.

Expected output: KEV-listed CVEs flagged and scheduled immediately.

1. Set thresholds as policy, not per-CVE debate: for example, EPSS above 0.5 or KEV-listed gets patched in 7 days; high CVSS with low EPSS gets 30. Write it down so triage is mechanical.

Expected output: a one-page SLA table the team follows without meetings.

1. Re-score on a cadence. EPSS moves as exploit chatter changes; a CVE that was 0.05 last month can be 0.8 today. Refresh weekly and let risers jump the queue.

Expected output: a weekly diff showing which CVEs moved and what changed in the schedule.

Variant phrasings

"EPSS vs CVSS which to use"

Both. CVSS for worst-case severity, EPSS for likelihood, KEV for confirmation. One number never tells the story.

"how to prioritize vulnerabilities with limited staff"

Steps 2, 3, and 5 are the whole answer: probability times exposure, encoded as thresholds, so a small team works the right list.

"what is a good EPSS score threshold"

There is no universal number; calibrate against your capacity. Start with the top percentile band your team can actually clear each cycle and adjust.

Why this happens

CVSS was designed to describe vulnerabilities, not to rank your work, so severity-sorted queues bury teams in theoretical criticals while actively exploited mediums sit unpatched. EPSS was built from observed exploitation data specifically to answer "what gets attacked next", which is the question patching actually needs.

Edge cases and pitfalls

• EPSS is a 30-day probability, not a guarantee; low score does not mean safe, it means less urgent.
• New CVEs can lack EPSS data for a bit; fall back to CVSS plus exposure until the score lands.
• Do not EPSS-rank and then ignore asset criticality; a low-EPSS bug on the crown-jewel database still deserves attention.
• KEV membership can lag; threat intel about active exploitation beats any score.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mK0f3qK7aIhqOucCrjrOXg