Roll out in four phases: observe silently, comment on pull requests, block only new critical findings, then tighten. Baseline existing findings first so developers see only what their own change adds. A scanner that blocks on old debt on day one gets disabled by day three.
Why rollouts fail
The usual story: a team turns on a scanner, finds hundreds of existing issues, and enables blocking. Every pull request fails for reasons unrelated to the change. Developers complain, leadership allows an override, and the check becomes a rubber stamp.
The fix is sequencing, not a better scanner.
The four phases
| Phase | Mode | Typical length | Goal |
|---|---|---|---|
| 1. Observe | Runs, results hidden from developers | 1 to 2 weeks | Measure noise and runtime |
| 2. Comment | Results posted on pull requests | 2 to 4 weeks | Build trust, collect false positives |
| 3. Block | Fail on new critical findings only | Ongoing | Prevent regressions |
| 4. Tighten | Add high severity, lower thresholds | Quarterly | Raise the bar steadily |
The lengths are starting points. Adjust for your team's pace and the size of the backlog.
Baseline the past
Before phase 3, record the findings that exist today as a baseline. The pull request check then compares against it and reports only new ones. Existing issues go to a backlog with owners and a burn-down plan, and do not hold up unrelated work.
Tune before you block
During phase 2, collect every false positive and decide what to do with each: adjust a rule, mark a finding as not applicable with a reason, or report it to the tool's maker. Prioritizing findings by whether vulnerable code is actually reachable also cuts noise considerably.
A useful measure before blocking is the share of comments developers act on. If most are ignored, the rule is not ready.
Communicate
- Tell teams the dates for each phase in advance.
- Publish what will block and what will not.
- Describe the exception process and who approves.
- Give a channel for questions.
- Report results after phase 2, including what changed because of feedback.
Handling pushback
Developers who push back usually have a point about noise or speed. Treat it as input. A rule that annoys people and finds nothing real should be removed.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the finding counts before and after reachability filtering, since that gap is much of the noise you want gone before blocking.
Where Safeguard fits
Safeguard offers reachability analysis to cut noise and policies and gates where each rule can be set to comment or block. Try a scan at https://gold.safeguard.sh/scan.
Quick check
How long should the comment phase last?
Long enough to see real false positives and for people to trust the output, often a few weeks. Move on when most comments are acted on.
What if a team refuses to adopt it?
Find out why. Common causes are noise, slowness, or unclear ownership. Fix those before enforcing.
Last reviewed: 19 October 2026.
