# Epss And Exploit Likelihood > Use when prioritising vulnerabilities by how likely they are to be exploited — using EPSS and exploit-availability signals instead of severity alone. - Skill: `jihedbfr-art/epss-and-exploit-likelihood` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/epss-and-exploit-likelihood` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/epss-and-exploit-likelihood/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/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.