EPSS score: how to use it for patch prioritization

Not specified by the original author.

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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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

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

Thread query: 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.

Not specified by the original author.

agent's CVE prioritization ignored EPSS: severity-only ranking fix

TL;DR

The agent ranked CVEs by severity alone, so theoretical criticals outranked actively exploited highs. Blend EPSS (exploit prediction) with severity: patch what is likely to be exploited first. Severity measures impact; EPSS measures probability; you need both.

agent's CVE prioritization ignored EPSS (severity-only ranking)

Steps

1. Pull EPSS scores for the open CVEs alongside their CVSS. Expected: Each CVE has both numbers.

2. Re-rank by a blend: high EPSS first, then severity. Expected: The order changes meaningfully.

3. Patch in the new order; track time-to-patch for high-EPSS items specifically. Expected: The exploited get fixed first.

4. Make the blend the default ranking in the agent. Expected: Future prioritization includes EPSS.

5. Review the severity-only backlog for items the new ranking would have caught sooner. Expected: The cost of the old ranking is known.

When to use

• patching order ignores exploit likelihood
• prioritization is severity-only
• actively exploited CVEs wait

When not to use

• EPSS data is unavailable for the stack (use CISA KEV as the alternative)
• the environment cannot be exploited remotely (context matters; adjust)
• all CVEs are patched promptly anyway (ranking is moot)

Tool compatibility

• EPSS
• CVE prioritization

Variant phrasings

• "CVE prioritization ignored EPSS"
• "severity-only ranking CVE"
• "EPSS exploit prediction patching"

Why it happens

CVSS severity measures how bad exploitation would be, not how likely it is. Most criticals are never exploited; some highs are exploited within hours. EPSS estimates the probability, and the combination is what prioritization should optimize: expected harm, not hypothetical harm. Severity-only ranking patches ghosts while the exploited wait.

Edge cases

• EPSS is a probability, not a certainty; high-severity still matters
• CISA KEV is the ground truth for 'exploited now'; EPSS is the forecast
• the blend weights are a policy decision; document them

Provenance

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

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

Thread query: agent's CVE prioritization ignored EPSS: severity-only ranking fix

TL;DR: The agent ranked CVEs by severity alone, so theoretical criticals outranked actively exploited highs. Blend EPSS (exploit prediction) with severity: patch what is likely to be exploited first. Severity measures impact; EPSS measures probability; you need both.

Not specified by the original author.

TL;DR

EPSS republishes with a retrained model roughly monthly, and a retrain can move a CVE's score dramatically with no change in the underlying threat. The score is a relative probability of exploitation in the next 30 days, calibrated against the model's training window, not a meter reading of current attacker activity. Check the model date when you see a swing, combine EPSS with KEV membership and your own exposure, and never auto-close a CVE because its EPSS dropped.

The query

EPSS score fell from 0.9 to 0.02 overnight with no new information - the model retrained

Use this when

• An EPSS score swings wildly between daily pulls with no related news
• A prioritization queue reorders itself overnight
• Someone proposes closing or deprioritizing CVEs on a score drop alone

Not for

• EPSS API errors or missing scores (a data problem)
• Choosing between EPSS and CVSS (use both, they measure different things)
• Predicting exploitation for a specific environment (EPSS is population-level)

Steps

1. Check the model date on both scores

EPSS publishes the model version and date. Compare the model behind the 0.9 with the model behind the 0.02.

Expected output: confirmation that a retrain happened between the two readings.

2. Look at percentile, not just probability

A score of 0.02 can still be a high percentile if the whole distribution shifted. The percentile tells you where the CVE ranks relative to everything else, which is what prioritization actually needs.

Expected output: the CVE's rank context, which often moves less violently than the raw score.

3. Cross-check with KEV and threat intel

If the CVE is in the CISA KEV catalog, it is being exploited regardless of what the model says this month. KEV membership outranks any EPSS swing.

Expected output: a verdict that survives the model retrain.

4. Freeze prioritization inputs around retrains

When a new EPSS model publishes, re-baseline the queue deliberately instead of letting the raw scores reshuffle it overnight. Review the biggest movers by hand.

Expected output: a queue that changes for reasons you can explain.

5. Ban score-drop auto-closure

Encode the rule: no CVE is closed or deprioritized on an EPSS decrease alone. Closure needs positive evidence (patched, not affected, KEV-removed with analysis). Verify: the automation cannot produce a "closed because EPSS fell" outcome.

Variant phrasings

EPSS score dropped overnight no new information

The short symptom search.

EPSS model retrain score change explained

The cause-first search.

Compatibility: EPSS data as published by FIRST. Applies to any pipeline consuming daily EPSS scores.

Why it happens

EPSS is a machine-learning model trained on historical exploitation data, and it is retrained periodically with new features and new training windows. A retrain changes the model's view of every CVE at once, including ones with no new activity. The score is also relative: it estimates probability against the current population, so population-level shifts move individual scores without any individual change.

Edge cases / pitfalls

• A rising EPSS deserves the same skepticism as a falling one. Do not let a model retrain manufacture urgency either.
• EPSS covers the next 30 days. For long-lived prioritization decisions, the KEV catalog and your exposure matter more than this month's probability.
• Daily EPSS pulls that skip the model-date check will misattribute every retrain to "the threat changed". Log the model date with every pull.
• Combining EPSS with CVSS by multiplication is folk math. Use them as separate signals in a documented prioritization rubric instead.

Provenance

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

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

Thread query: EPSS score fell from 0.9 to 0.02 overnight with no new information - the model retrained

TL;DR: EPSS republishes with a retrained model roughly monthly, and a retrain can move a CVE's score dramatically with no change in the underlying threat. The score is a relative probability of exploitation in the next 30 days, calibrated against the model's training window, not a meter reading of current attacker activity. Check the model date when you see a swing, combine EPSS with KEV membership and your own exposure, and never auto-close a CVE because its EPSS dropped.