Block the pull request only for new findings the change itself introduces, at a severity your team has agreed is urgent. Comment on the rest. A gate that blocks on old, unrelated issues trains people to route around it. A gate that never blocks becomes background noise.
Two modes, two purposes
A blocking check stops the merge until it passes. A commenting check posts results and lets the merge proceed. Both are useful, but they answer different questions.
- Commenting says: here is what we found, please look.
- Blocking says: this must be fixed or formally excepted before it ships.
Start in commenting mode. Move specific rules to blocking once you trust their accuracy.
What to block on
Good candidates for blocking are narrow:
- A new dependency with a critical known vulnerability that your code actually reaches.
- A new use of a code pattern your team has already banned.
- A change that breaks a policy you wrote down, such as a disallowed license.
Everything on that list has a clear owner (the author) and a clear fix. If you cannot say who fixes it, do not block on it.
What to leave as a comment
Leave existing debt, low-severity issues, and anything with high false-positive rates as comments or tickets. Old findings are a backlog problem, not a pull request problem. Mixing the two means a developer fixing a typo has to resolve a three-year-old advisory.
How team size changes the answer
| Team size | Suggested starting mode |
|---|---|
| 1 to 10 | Comment first, block only on critical new findings |
| 10 to 50 | Block on new high and critical, comment on the rest |
| 50 and up | Central policy with per-repo overrides, blocks tied to risk tiers |
The bigger the team, the more you need the rule written down, because nobody can negotiate each case in chat.
Make blocking actually enforceable
A check that is not required can be merged around. In GitHub, branch protection offers a setting that requires status checks before merging, and the documentation says those checks must be successful, skipped, or neutral. Note that skipped counts as passing, so make sure your scan job cannot silently skip.
Add an exception path too. When a block is wrong, a developer needs a documented way to get a time-limited waiver with a named approver. Without it, people disable the check.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what changes between a pass, a comment, and a block, and which finding triggers each.
Where Safeguard fits
Safeguard supports policies and gates on pull requests, so you can set which findings block and which only comment. Try a scan first at https://gold.safeguard.sh/scan.
Quick check
Is it bad to block on everything?
It usually backfires. Developers disable or bypass a noisy gate. Block on a short, accurate list and comment on the rest.
Can a skipped check let a risky change merge?
In GitHub, a skipped status counts as passing for required checks. Configure the job so it runs on every pull request and fails loudly if it cannot scan.
Sources
Last reviewed: 19 October 2026.
