Block a build when a finding is serious, reachable in your code and has a fix available. Warn on serious findings you cannot yet fix or that are not reachable. Log low severity findings for trend tracking. Start with a narrow blocking rule so developers trust the gate, then widen it deliberately.
Definitions
Block. The pipeline fails and the change cannot merge or deploy.
Warn. The pipeline passes, but the finding appears on the pull request and in a report with an owner and a due date.
Log. The finding is recorded for trend and audit, with no developer action required.
Decision table
| Finding | Reachable or exploitable | Fix available | Action |
|---|---|---|---|
| Critical or high vulnerability | Yes | Yes | Block |
| Critical or high vulnerability | Yes | No | Warn, add a mitigation and an owner |
| Critical or high vulnerability | No, or not reachable | Yes | Warn, schedule the update |
| Critical or high vulnerability | No, or not reachable | No | Log, review quarterly |
| Medium | Any | Any | Warn on new ones, log existing |
| Low | Any | Any | Log |
| Hardcoded secret | Not applicable | Not applicable | Block, rotate |
| Disallowed license | Not applicable | Not applicable | Block, per your policy |
| Scanner failure or timeout | Not applicable | Not applicable | Decide in advance, see below |
These are example defaults, not a standard. Set yours from your risk appetite and your contracts.
Rules that keep a gate trusted
- Gate on new findings first. Blocking on old backlog stops everyone and teaches people to bypass.
- Show the reason. A failed check should say which package, which finding, and what upgrade fixes it.
- Make exceptions expire. A waiver without an end date becomes permanent.
- Decide what happens when the scanner is down. Fail closed for production deploys, and fail open with a loud alert for ordinary pull requests, or the reverse if your risk says so. Write it down.
- Review blocks and bypasses monthly. Many bypasses mean the rule is wrong or the fix path is unclear.
Why reachability changes the table
A vulnerable function that your code never calls is a different problem from one on a hot path. Reachability analysis separates the two, so you can block on what matters and warn on the rest rather than blocking on every advisory.
Try it yourself
Click through it at your own pace, or open it full screen. Compare how many findings remain once unreachable ones are set aside.
Quick check
Should every critical finding block?
Not always. A critical finding in unreachable code with no fix may warrant a warning and a mitigation, not a blocked release.
Where do I start if we have no gate today?
Block only on new critical issues with a fix available, and watch the results for a few weeks.
Safeguard policies, gates and guardrails can encode rules like these, with reachability analysis to separate exploitable findings from the rest. Try the free scan.
Last reviewed: 19 October 2026.
