Using EPSS with CISA KEV without turning triage into arithmetic
Vulnerability teams rarely lack alerts. The harder problem is explaining why one CVE receives scarce remediation time while another waits. Severity scores describe potential impact, but they do not say whether exploitation is likely in the next month or whether attackers have already used the vulnerability. The Exploit Prediction Scoring System, or EPSS, and the CISA Known Exploited Vulnerabilities catalog can fill different parts of that gap when they are used with asset context.
EPSS estimates the probability that a vulnerability will be exploited in the next 30 days. It publishes a score between zero and one and a percentile ranking across scored vulnerabilities. The score is not a statement that a specific organization will be attacked, and the percentile is a ranking of the CVE population, not a measure of the organization's exposure.
The KEV catalog is a different signal. CISA adds vulnerabilities when there is evidence of exploitation in the wild and requires federal civilian agencies to remediate them under the applicable binding operational directive. Other organizations can use the catalog as a prioritization input, but they should not assume that absence from the catalog means a vulnerability has not been exploited.
Use the signals for different decisions
A useful triage policy separates three questions:
- Is exploitation likely?
- Is exploitation already known to occur?
- Would exploitation matter in this environment?
EPSS helps with the first question. KEV helps with the second. Asset inventory, exposure, privilege, data sensitivity, business process, and compensating controls answer the third.
A high EPSS score on a package that is installed but never reachable should not automatically displace a medium score on an Internet-facing service with a known exploitation path. A KEV entry on a component with no affected version in production should not create a production incident, but it should still be checked to prove that conclusion.
Do not multiply EPSS by CVSS or another ordinal scale and call the result a probability. FIRST's guidance warns that combining a calibrated probability with a ranking produces a value with no interpretable meaning. If a workflow needs a composite priority, keep the components visible and document the decision rule.
Build a repeatable enrichment step
Store the source CVE, EPSS score, percentile, retrieval time, and the KEV flag with the finding. Preserve the original vulnerability data so that a later score change does not rewrite history. A retrieval failure must remain an error or an unknown value, not a silent zero.
Pull the daily EPSS data through the published CSV or repository when processing a large inventory. Use the API for small lookups where its design fits the workflow. Cache the KEV list with its update time and record which snapshot informed a decision.
When a score changes, determine whether the change is meaningful for the decision. A move from the 80th to the 82nd percentile may not justify a new work item, while a substantial probability increase or a new KEV entry may. Use thresholds as review triggers, not as a substitute for ownership.
Make exposure evidence explicit
For each affected asset, record the affected version or configuration, the route by which an attacker could reach it, and the privilege or data the vulnerable component can access. A package inventory can show presence without proving exploitation. A network scan can show a service without proving the exact vulnerable version. State the difference in the ticket.
Where a safe verification method exists, test the vulnerable condition in a controlled environment. If telemetry can show exploitation attempts, preserve the relevant logs and the query used. Do not use an absence of alerts as proof of safety when logging does not cover the path.
Compare findings against the organization's own service inventory. A CVE in a development dependency may be urgent if it is shipped in a production container. A CVE in a management interface may be urgent even when the package is not directly exposed, because administrators often have powerful credentials and broad reach.
Document exceptions and review dates
Risk acceptance is a legitimate outcome, but it needs a reason and an expiry. Record who accepted the risk, what compensating control exists, what evidence supports that control, and when the decision will be reviewed. Revisit the exception when the EPSS score, KEV status, asset exposure, or affected version changes.
A KEV due date is not a universal compliance deadline outside the organizations covered by the relevant directive. It is still a strong reason to confirm exposure and prepare a remediation path. Internal policy should state how KEV entries affect service-level targets and how emergency changes are authorized.
Keep the response plan practical. Some fixes require a vendor patch, while others can be reduced by disabling a feature, restricting access, rotating credentials, or moving a service behind an authenticated proxy. A mitigation that only hides a vulnerable endpoint without preventing exploitation may reduce urgency, but it does not remove the finding.
Measure whether the process improves decisions
Track how often enriched findings change priority, how long KEV items remain open, how many high-EPSS items lack a valid asset owner, and how often an exception is renewed without new evidence. Review a sample of closed findings to confirm that the remediation evidence matches the claimed version or configuration.
Report uncertainty alongside the decision. A score can be useful even when it is wrong for a particular asset, provided the team records the assumptions and revisits them. The goal is not to predict every attack. It is to direct attention toward vulnerabilities that are both plausible and consequential in the estate the organization actually runs.
Top comments (0)