Safeguard
Security Guides•

Prioritise vulnerabilities with KEV, EPSS and reachability

Three signals that shrink a long vulnerability list: CISA KEV for known exploitation, EPSS for likelihood, and reachability for whether your code calls it.

Safeguard Security Team
3 min read

Combine three signals. First, whether a flaw is on CISA's Known Exploited Vulnerabilities list. Second, its EPSS score, which estimates the chance of exploitation in the next 30 days. Third, whether your code actually reaches the vulnerable function. Severity score alone is a poor way to order work.

Signal one: known exploitation

CISA maintains the Known Exploited Vulnerabilities catalog and describes it as the authoritative source of vulnerabilities exploited in the wild. The page says organisations should use it as an input to their vulnerability management prioritisation framework. Entries carry a date added and a due date, and the catalog can be downloaded as CSV or JSON, which makes it easy to join against your own findings.

A KEV match is the strongest signal on this list: someone has already used it against a real target.

Signal two: likelihood

FIRST's Exploit Prediction Scoring System is a data-driven model that estimates the probability that a published CVE will be exploited in the wild within the next 30 days. Scores run from 0 to 1, with percentile rankings, and are published every day for every CVE. The data is free through CSV downloads and an API.

EPSS helps with items that are not on KEV yet. A high score on a non-KEV item is a reason to look sooner. Do not treat a low score as a guarantee. The page itself points to guidance on thresholds, combining EPSS with CVSS and KEV, and avoiding misuse.

Signal three: reachability

A vulnerable package in your tree is not the same as a vulnerable code path in your program. Reachability analysis asks whether your code can call the affected function. If it cannot, the finding drops in urgency. If it can, it moves up.

Reachability has limits. Dynamic dispatch, reflection and plugins can hide calls from static analysis, so treat "not reachable" as "lower priority", not "ignore forever".

A simple scoring routine

  1. On KEV and reachable: fix now.
  2. On KEV, reachability unknown: treat as fix now until shown otherwise.
  3. High EPSS and reachable: next in the queue.
  4. High severity, low EPSS, not reachable: schedule with routine updates.
  5. Everything else: batch into regular maintenance.

Write the thresholds down so two engineers reach the same decision. Revisit them each quarter.

What to record

For each decision, note the date, the signals used and who approved any delay. When an auditor or a customer asks why a critical was left open, a dated note is a better answer than a memory.

The interactive demo below shows the effect of filtering by reachability.

Where Safeguard fits

Safeguard provides reachability analysis, and its vulnerability and zero-day views can sit next to known exploitation data. The free scan at gold.safeguard.sh/scan is a no-login start.

Click through it at your own pace, or open it full screen.

Quick check

Is EPSS the same as CVSS?

No. CVSS rates severity. EPSS estimates the probability of exploitation within 30 days.

If a CVE is not on KEV, is it safe to ignore?

No. KEV lists known exploited items. Others may still be exploited or become so.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.