Start in warn mode, measure how often a finding is real, and move to blocking only for a narrow set of high confidence rules once the team trusts them. Blocking on day one with noisy rules teaches developers to bypass the check. Blocking too late means the tool never changes anything.
The three modes
Most tools can run a pull request check in one of three ways.
Report only. The result is posted but the check passes. Good for the first two weeks.
Block on selected rules. The check fails only for rules you name, or findings above a confidence level. This is where most teams should settle.
Block on everything above a severity. Simple to explain, but severity is a poor proxy for whether a result is real. Use it only if the tool's high severity results have proven accurate on your code.
A decision table in words
Block when all of these are true: the rule has produced real findings in your own pilot, the fix is usually small, a developer can see why it fired, and there is a fast way to appeal.
Warn when any of these is true: the rule fires on patterns your frameworks handle elsewhere, the fix needs design discussion, or the team has not seen the rule before.
Do not run a rule at all if triage shows it is wrong more often than right on your stack, and the vendor cannot tune it.
Things to check in the tool before you gate
- New code only. Can the check judge only the lines a pull request changes? If it fails every merge because of old findings, nobody will accept it.
- Appeal path. Can a developer dismiss a finding with a reason, and does a second person see it? A gate with no escape gets worked around, often by disabling the check.
- Outage behaviour. Decide in advance what happens when the scanner is unavailable. Fail open for a short window with an alert is common. Decide it deliberately.
- Speed. A check that takes twenty minutes will be run less often, or skipped by setting merges to bypass. Measure it in the pilot.
- Status check wiring. Confirm the check is a required status check on protected branches, and that skipped checks cannot pass silently.
Roll out in stages
Week one and two: report only. Collect a simple count of findings per rule and how many were real.
Week three: pick the two or three rules with the strongest record and block on them. Announce it, with the appeal route in the message.
Month two onward: add rules one at a time. Each addition gets a short note in the team channel explaining what it catches and how to fix it.
Review the blocked and dismissed lists every month. A rule with many dismissals is telling you something about either the rule or the training.
What about secrets and dependencies
Hardcoded credentials are a good first blocking rule because the cost of a false negative is high and the fix is clear. For dependencies, a gate that checks whether a vulnerable function is actually reachable creates far less friction than one that blocks every advisory.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which conditions pass the gate and which stop it.
Quick check
Is blocking always safer than warning?
Not if the check is noisy. Developers route around checks they distrust, which leaves you with a gate that exists on paper only.
Who should own the list of blocking rules?
A named person in the security or platform team, with a monthly review. Rules without an owner drift.
Safeguard offers policies and gates for pull requests, and reachability analysis for dependency findings. You can run a free check at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
