Gate on how likely, not only on how bad.

Combined, they answer three questions

FIRST's guide to using EPSS draws the line between the last two:

One is a record of history. The other is a forecast.

As a general rule of thumb: when a vulnerability appears on CISA KEV, treat it as actively exploited and prioritize accordingly, regardless of EPSS score.

FIRST, Using EPSS

Where severity alone gets it backwards

These are findings from Terramantle's own provider scans, scored against the FIRST feed of 7 November 2026. The severity-only column is a plain CVSS >= 7 rule, and it gets both of the first two rows wrong in the expensive direction.
The 9.8 blocks a pipeline and pulls an engineer onto a fix for a CVE that FIRST gives a 0.4% chance of being exploited this month: a day of work, a delayed release, and no risk removed.
The 5.9 passes, and that CVE is more likely to be exploited than 99.8% of everything FIRST scores, so the one vulnerability an attacker is actually using ships without a review.

CVSS is not wrong in either row. It answers how bad, which is the question it was built for. The policy asked it how likely, and it has no opinion.

Thresholds: percentiles, not round numbers

The obvious EPSS rule is "block anything above 0.5". FIRST is blunt about it:

You may think that a threshold at 50% is sane, but it's not (since the base rate is around 2%), and setting a threshold at 50% deprioritizes the 98.8% of all published vulnerabilities.

FIRST, Using EPSS

Scores are long-tailed. On the 7 November 2026 feed, 401,675 CVEs had a median score of 0.006, so a cutoff like 0.5 sits far out on the tail. Terramantle's rules threshold on the percentile instead. "The top 1%" still means the top 1% after FIRST recalibrates its model, where a fixed probability would quietly select a different share of CVEs each time.

Before settling on the 99th percentile as the blocking default, Terramantle ran it against the catalogue. It matched 930 of the 1,731 provider versions with CVE findings, where "no critical vulnerabilities" matches 78%. Almost all of those come from two Go CVEs, Terrapin and the HTTP/2 CONTINUATION flood, and it matched only 10 of the 254 provider builds Terramantle has patched itself.

One Terramantle policy, three signals

Each finding f in input.findings carries the per-CVE values, and input.scan.vulnerabilities carries the rollups for the version. Every signal has a way of being absent, and a rule that does not say what it does then fails open:

This policy reads all three. It was checked with opa eval against a clean input and a failing one. CVSS and EPSS meet in the third rule as AND, and the last rule honours the org's on_missing_signal setting for both catalogues:

package terramantle.policy

# KEV: exploitation has been observed. Blocks whatever EPSS or CVSS say.
deny contains msg if {
  some f in input.findings
  f.meta.kev
  msg := sprintf("%s is on the CISA KEV catalogue", [f.rule_id])
}

# EPSS: exploitation is likely. The top 1% of all scored CVEs, whatever the severity.
deny contains msg if {
  some f in input.findings
  f.category == "vulnerability"
  f.meta.epss_percentile >= 0.99
  msg := sprintf("%s is in the top 1%% of CVEs by EPSS (%.2f)", [f.rule_id, f.meta.epss])
}

# CVSS AND EPSS: severe if exploited, and at least as likely as a CVSS-Critical-sized
# population (FIRST's 90th-percentile equivalent). Severe-but-unlikely is left to an
# advisory CVSS ceiling rather than blocked. Never multiply the two.
deny contains msg if {
  some f in input.findings
  f.meta.cvss_score >= 9.0
  f.meta.epss_percentile >= 0.90
  msg := sprintf("%s is critical (CVSS %.1f) and above the 90th EPSS percentile", [f.rule_id, f.meta.cvss_score])
}

# Missing signals, honouring the org's setting.
deny contains msg if {
  input.settings.on_missing_signal == "hard_fail"
  some name, value in {"KEV": input.scan.vulnerabilities.kev_count, "EPSS": input.scan.vulnerabilities.epss_floor}
  value == null
  msg := sprintf("%s data unavailable and the signal-fail gate is set to Hard Fail", [name])
}

The Terramantle policy editor ships the rules as separate templates, so each can be enforcing or advisory on its own:

• Block actively exploited CVEs: KEV, covered on the KEV policy page.
• Block likely-exploited CVEs (EPSS): at the 99th percentile.
• Likely and unfixable: at the 90th percentile, for CVEs with no fixed version.
• CVSS ceiling: keeps severe-but-unlikely findings visible.

What this does not do

It does not produce a combined risk score; multiplying CVSS by EPSS is the "score laundering" FIRST warns against. It does not know your environment: EPSS forecasts exploitation across the internet, not whether the vulnerable path is reachable in the way you use a provider.

It is not a live feed; the mirror is daily and keeps no history, so a policy cannot react to a score that jumped this week. It does not make low scores safe, and below the 0.04 floor it cannot tell 0.03 from 0.0001. And it applies to providers only, because modules, state and plans carry no CVE findings for EPSS to score.