A policy gate reads fields from scan output, such as severity, known exploitation, reachability, fix availability and finding age, then applies rules that pass, warn or block a change. The gate is only as good as those fields. If they are missing or stale, it either blocks too much or lets risk through.
The fields a gate can use
| Field | Example rule | Risk if the field is wrong |
|---|---|---|
| Severity and its source | Block on high or above | Blocks on a score that ignores context |
| Known exploitation (KEV) | Always block | Misses issues if data is stale |
| Exploit probability (EPSS) | Warn above a chosen threshold | Threshold set without review |
| Reachability | Block only if reachable | Unknown treated as safe |
| Fix available | Block if a fix exists | Suggests unfixable work |
| New versus existing | Block only new findings | Hides old debt forever |
| Age | Escalate after a set number of days | Clock starts at wrong date |
New versus existing is the key choice
On a codebase with years of debt, gating on every finding blocks all work. Gating on new findings only keeps the line from getting worse. SARIF models this with baseline states: a result can be new, unchanged, updated or absent relative to a baseline run. A gate that reads that state can fail only on new results while a separate backlog plan handles the rest.
Three outcomes, not two
Use pass, warn and block. Warn gives developers information without stopping work, and it helps you tune rules before they bite. Many teams start new rules as warnings for a few weeks, check the volume and the false positive rate, then promote the ones that earn it.
Rules that tend to hold up
- Block when a finding is in the CISA Known Exploited Vulnerabilities catalog and is present in what you ship.
- Block new high severity findings that are reachable and have a fix.
- Warn on new findings with a high EPSS score, since that score is a 30 day probability, refreshed daily.
- Warn, do not block, when reachability is unknown.
- Allow exceptions only with an owner, a reason and an expiry date.
Thresholds are yours to set. FIRST states that EPSS has no insight into your context, so numbers should reflect your own environment and appetite.
Gate hygiene
- Show the reason for a block in the pull request itself, with the field that triggered it.
- Keep a documented override path with approval, so urgent fixes are not stuck.
- Log every override.
- Review rule hit rates monthly, and drop rules that only produce noise.
A gate that people route around is worse than none, because it creates false confidence.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice which finding fields cause a pull request to be blocked and which only produce a warning.
Where Safeguard fits
Safeguard provides policies, gates and guardrails that act on scan results, including reachability analysis, so you can write rules like those above. Start with a free scan.
Quick check
Should a gate block on every high severity finding?
Not on an existing codebase. Start with new findings and reachable, fixable ones, then work the backlog separately.
What should happen when reachability is unknown?
Usually a warning with review, not a silent pass. Unknown means the analysis could not decide.
Sources
Last reviewed: 19 October 2026.
