A release gate should block on a short, written rule, not on every finding. A sensible start is to stop the release for vulnerabilities that are known to be exploited, reachable in your code, and have a fix available. Track everything else with an owner and a due date.
Why "block on all high severity" fails
Severity labels describe how bad a flaw could be. They do not tell you whether anyone is attacking it or whether your code even calls the vulnerable function. A gate that blocks on every high severity finding trains teams to find ways around it, and in a regulated release process a bypassed gate is worse than no gate, because it leaves a record of ignored controls.
Three signals make a rule more useful than severity alone.
| Signal | What it tells you | Public source |
|---|---|---|
| Known exploited | Attackers are using it now | CISA Known Exploited Vulnerabilities catalog |
| Exploit probability | Likelihood of exploitation in the next 30 days | EPSS, published daily |
| Reachability | Whether your code path can trigger it | Your own analysis |
CISA says organizations should use the KEV catalog as an input to their vulnerability management prioritization framework. The word "input" matters. KEV is one signal, not the whole policy. EPSS estimates the probability that a published CVE will be exploited in the wild within the next 30 days, as a value from 0 to 1, updated every day.
A starting rule you can write on one page
- Block if a finding is on the KEV catalog and the affected component ships in the release.
- Block if a critical finding is reachable and a fixed version exists.
- Warn, and open a ticket with a due date, for everything else.
- Allow a documented waiver with an owner and an expiry for any block you cannot clear (see the post on how long a waiver should last).
Write the thresholds into the pipeline as policy, not into a wiki page. A rule that lives only in a document gets applied unevenly.
Decide what the gate looks at
State the scope. Production dependencies and the final container image belong in scope. Test-only tooling usually does not. Say so in the policy, so an auditor reading it does not have to guess.
Also decide what happens when the scanner itself fails. Fail closed for regulated releases, with a named person who can authorize a manual review. If you leave this undefined, the first outage will define it for you.
Review the rule on a schedule
Thresholds go stale. Review them each quarter against what the gate actually blocked and what later turned out to matter. If the gate blocks often and teams override it often, the rule is too tight. If it never blocks, it is probably too loose or scanning the wrong thing.
Try it yourself
Click through it at your own pace, or open it full screen.
Click a failing check and look at which finding caused it and what the policy says about it.
Safeguard supports policies and gates that can block a pull request, along with reachability analysis and dependency scanning, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Should a gate block on CVSS score alone?
Usually not. CVSS describes severity, not exploitation or reachability. Pair it with KEV status, EPSS and reachability so the gate stops what matters.
Is EPSS a replacement for KEV?
No. KEV lists vulnerabilities known to be exploited. EPSS estimates future exploitation probability. They answer different questions, so use both.
Sources
Last reviewed: 19 October 2026.
