Prioritizing Vulnerabilities with EPSS and KEV: A Method for SMBs

A monthly vulnerability scan across a mid-sized SMB fleet routinely surfaces 300 to 800 open CVEs, spread across servers, workstations, network appliances, and third-party applications. The part-time security lead who receives that report has neither the team nor the hours to triage every line. The question is not "how many vulnerabilities do we have," it is "which ones do I fix this week, with the two people I have." EPSS and KEV answer exactly that question, provided they are used as an operational filter rather than a compliance checkbox.

What EPSS and KEV actually measure, and why they complement each other

KEV (Known Exploited Vulnerabilities) is the catalog maintained by CISA that lists CVEs with confirmed active exploitation observed in the field, reported through real incidents, threat intelligence, or honeypots. An entry in KEV is not a guess: it is an observed fact. The catalog is updated continuously and typically carries a remediation deadline for US federal agencies, a deadline that has become a de facto reference for the private sector as well.

EPSS (Exploit Prediction Scoring System) is a probabilistic score, maintained by FIRST, that estimates the likelihood a given CVE will be exploited within the next 30 days, on a scale from 0 to 1. The model draws on dozens of signals (public exploit code, social media and forum chatter, vulnerability class, product exposure) and is recalculated daily for every published CVE.

The complementarity comes down to one sentence: KEV tells you what has already happened, EPSS tells you what is likely to happen next. KEV has narrow coverage but total reliability (if it is in there, it is being exploited). EPSS has broad coverage (every CVE gets a score) but probabilistic reliability (a high score is not a certainty). Relying on either one alone leaves a blind spot: KEV-only means reacting after the fact on the most publicized flaws; EPSS-only means missing that some moderately scored CVEs are already being exploited in targeted, confirmed campaigns.

The three-tier prioritization rule

For a SOC without 24/7 coverage, the rule has to fit on a single slide and require no case-by-case judgment call:

1. CVE listed in KEV: patch immediately. No debate, no standard maintenance window. This is confirmed exploitation happening somewhere on a product you also run. Treat it as an emergency, including outside your usual change window if the asset is exposed.
2. EPSS score above a threshold (typically 0.10 to 0.20 depending on risk appetite): short window. Fix within 7 to 14 days, in the next scheduled maintenance window, without waiting for the standard monthly patch cycle.
3. Everything else: backlog. These CVEs exist and are documented, but they join the standard remediation cycle (monthly patching, version upgrades). They warrant neither an on-call escalation nor a fire drill.

The EPSS threshold is not universal: an SMB with internet-facing critical assets should keep a lower threshold (0.05 to 0.10) than one whose footprint is mostly internal and segmented.

A worked example: from 412 CVEs to 6 actions

Take a representative case observed on a fleet of 60 servers and 120 workstations after a monthly scan:

412 open CVEs (raw scan output, all products combined)
  -> 88 CVEs affect a product/version actually deployed and exposed
  -> 24 CVEs have an EPSS score >= 0.10 OR appear in KEV
     - 3 of which are in KEV (confirmed exploitation)
     - 21 of which have EPSS >= 0.10 but are outside KEV
  -> after contextualizing by asset exposure (internet-facing,
     critical segment, sensitive data): 6 CVEs retained for
     immediate action or a short remediation window

Out of 412 raw CVEs, 6 trigger a concrete action this week. The 3 KEV CVEs get patched within 48 hours. The other 3, high EPSS on exposed assets, are scheduled within 10 days. The remaining 406 join the standard monthly patch cycle without pulling the team into a fire drill. That is the difference between a 40-page report nobody reads and a 6-line list that gets handled within the week.

Automating it: enriching the vulnerability feed

The method only holds over time if the enrichment is automatic. The EPSS API and the KEV feed are both public and queryable without authentication, which makes it straightforward to build a simple daily enrichment pipeline:

# Fetch the EPSS score for a given CVE
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-31337" | jq '.data[0].epss'
 
# Check presence in the CISA KEV catalog
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | jq --arg cve "CVE-2026-31337" '.vulnerabilities[] | select(.cveID == $cve)'

On top of that, a daily scoring rule can be expressed simply:

scoring_rules:
  - condition: "cve.in_kev == true"
    priority: immediate
    sla_hours: 48
  - condition: "cve.epss_score >= 0.10"
    priority: short_window
    sla_days: 10
  - condition: "default"
    priority: backlog
    sla_days: 30

The critical point: EPSS moves over time, sometimes sharply from one day to the next after a public exploit gets published. A CVE scored at 0.03 last week can jump to 0.40 overnight. Enrichment frozen at the moment of the initial scan goes stale fast. Re-scoring has to run daily, across the entire stock of open CVEs, not just newly discovered ones.

The traps that undermine the method

Three pitfalls show up consistently across deployments of this approach:

• EPSS is not a fixed value. A score checked once during the monthly scan is a snapshot that expires within days. Without daily re-scoring, you miss the CVEs that tip into critical territory after an exploit gets published.
• KEV is not exhaustive. The catalog lists confirmed and reported exploitation, not all real-world exploitation. Many targeted campaigns never make it into KEV, or do so with a delay. A CVE's absence from KEV does not mean it is safe, only that no exploitation has been formally reported so far.
• The score alone is not enough, it must be contextualized by exposure and asset. A CVE with an EPSS of 0.25 on an isolated internal server with no external network access does not deserve the same treatment as the same CVE on an internet-facing server holding customer data. EPSS and KEV give you the generic triage, asset inventory and exposure give you the final call.

A feed already prioritized, not a raw stream to sort yourself

Building this pipeline (EPSS retrieval, KEV tracking, thresholds, daily re-scoring, cross-referencing against an asset inventory) is an engineering investment few SMBs can sustain in-house over time. The logic is simple to state, but keeping it current, day after day, across hundreds of CVEs, is ongoing work.

That is exactly what the ThreatClaw vulnerability feed delivers: incoming CVEs already carry EPSS and KEV enrichment, are already sorted under the three-tier rule, and get re-scored daily. The security lead receives a short list of real actions, not a raw scanner export to work through alone.