Epss And Exploit Likelihood

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

Severity tells you how bad a vulnerability would be if exploited; it says nothing about whether it will be. Most published vulnerabilities are never exploited in the wild, so prioritising purely by CVSS severity means fixing a lot of scary-looking issues that no attacker will ever touch, while a modest-severity bug that's being actively exploited waits. This skill covers using exploitation-likelihood signals — chiefly EPSS — to prioritise by what attackers actually do.

When to use it

Every time you prioritise a remediation backlog, alongside the environmental context from the cvss-in-context skill. EPSS answers "how likely is this to be exploited soon?", which is a different and complementary question to "how bad is it?" and "how exposed is it in our environment?".

The signals

• EPSS (Exploit Prediction Scoring System) — a data-driven probability (0–1) that a given CVE will be exploited in the next 30 days, updated daily by FIRST. A CVE with EPSS 0.85 is far more urgent than one at 0.002, regardless of their CVSS scores.
• Exploit availability — is there public exploit code (Metasploit module, PoC on GitHub, exploit-db)? Available exploits raise real-world likelihood sharply.
• Known exploitation — is it confirmed exploited in the wild (CISA KEV — see that skill)? This is the strongest signal and overrides EPSS predictions with observed reality.

Procedure

1. Enrich every finding with EPSS — pull the EPSS score for each CVE (FIRST publishes a daily dataset/API) so each item in the backlog carries a likelihood, not just a severity.
2. Combine likelihood with severity and exposure, not in place of them. The useful prioritisation is roughly: impact (severity, adjusted to your environment) × likelihood (EPSS / exploit availability / KEV). A high-EPSS bug on an exposed, sensitive asset is the top of the queue.
3. Let known exploitation jump the queue. If a CVE is KEV-listed or has a working public exploit, treat it as urgent almost regardless of its CVSS base score — observed/available exploitation beats predicted.
4. Use EPSS to de-prioritise the improbable. A CVSS 9+ with EPSS 0.001, no public exploit, and no exposure is defensibly not an emergency — a data-backed reason to schedule rather than scramble.
5. Re-check periodically — EPSS updates daily and exploit availability changes; a low-likelihood CVE can spike when an exploit drops. Rising EPSS on an exposed asset is a "fix this now" trigger.
6. Feed the combined score into triage and SLAs so the backlog is ordered by real risk, and the "why" is explainable to stakeholders.

Cheatsheet

the question EPSS answers
  CVSS severity  = how BAD if exploited
  EPSS           = how LIKELY to be exploited (next 30 days, 0..1, daily)
  KEV / exploit  = is it exploited/exploitable NOW (observed reality)

prioritise by:  impact (severity + your exposure)  ×  likelihood (EPSS / exploit / KEV)

jump-the-queue (fix now, near-regardless of CVSS base)
  KEV-listed | working public exploit | high EPSS + exposed asset

de-prioritise (schedule, don't scramble)
  high CVSS but EPSS ~0, no public exploit, not exposed

sources: FIRST EPSS (first.org/epss, daily API) ; CISA KEV ; exploit-db / GitHub
re-check: EPSS updates daily -> rising EPSS on exposed asset = act

Reading the signals

• A high EPSS score = strong predicted likelihood of near-term exploitation; prioritise even if the CVSS is moderate. This is exactly what severity-only prioritisation misses.
• KEV-listed or public working exploit = observed/available exploitation; the strongest signal — treat as urgent and let it override a low base score.
• High CVSS but near-zero EPSS, no exploit, not exposed = probably safe to schedule normally; a data-backed reason not to treat it as an emergency, which frees effort for what matters.
• A CVE whose EPSS is climbing = likelihood is rising (often an exploit is emerging); on an exposed asset this is a "move it up now" trigger.
• A backlog ordered purely by CVSS = the common failure — it fixes improbable criticals while exploited mediums sit open. Layer likelihood in.

Making it work (the practice)

• Automate EPSS enrichment in the vuln pipeline so every finding arrives with a likelihood score, not just severity.
• Combine likelihood, severity, and exposure into the priority order (ties into cvss-in-context and kev-catalog-workflow); no single signal is sufficient alone.
• Set SLAs on the combined risk — KEV/high-EPSS/exposed → fast; high-severity-but-improbable → normal cycle.
• Re-evaluate on a cadence since EPSS and exploit availability move; rising likelihood is an action trigger.
• Explain the ordering to stakeholders using the likelihood data — it justifies both urgency and deferral (feeds the reporting skill).

Pitfalls

• Prioritising by severity alone. The core mistake this skill fixes — most high-severity CVEs are never exploited, so severity-only queues waste effort on the improbable and miss exploited mediums.
• Treating EPSS as the only signal. It's a probability, not certainty, and doesn't know your environment. Combine it with exposure and severity, and let KEV (observed) override.
• Ignoring the daily updates. A low-EPSS CVE can spike when an exploit drops; static prioritisation misses that. Re-check.
• Over-deferring on low EPSS. Low likelihood isn't zero; for a critical, exposed asset, weigh it carefully and document the decision rather than dismissing it.

References

• FIRST EPSS (first.org/epss) — model, data, and API
• CISA Known Exploited Vulnerabilities catalog
• The cvss-in-context, kev-catalog-workflow, and risk-acceptance-and-sla skills
• SANS / industry guidance on risk-based vulnerability prioritisation

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.