Move in four phases: scan in report mode, baseline what already exists, block only new high risk findings, then tighten by team as backlog shrinks. Never switch on blocking for existing debt on day one. That punishes teams for history and trains them to bypass the gate.
Phase 1: observe
Turn scanning on everywhere in report mode. No gates, no tickets yet. The goal is coverage and a first honest inventory. Track how many repositories have a scan result and how many manifests were parsed. If a tool cannot tell you what it failed to scan, fix that before moving on.
Send a short note to engineering leads explaining what is coming and when. Surprise enforcement is the fastest way to lose goodwill.
Phase 2: baseline
Record the findings that exist today as the baseline for each repository. From here on, "new" means introduced after the baseline date. This lets you say two honest things: legacy findings go to a scheduled backlog, and anything introduced now is the team's to fix now.
Ask your tool whether baselines are per repo, can be re-cut, and whether you can report new and inherited findings separately.
Phase 3: warn on new
Add pull request checks that comment on new high severity findings but do not block. Run this for two to four weeks. Watch two numbers:
- How often a comment would have blocked.
- How often developers disagree, and why.
False positives and unclear fixes get fixed here, while the cost is low. A reachability signal helps: findings in code paths your application never calls can be deprioritized so the first blocked builds are the ones that matter.
Phase 4: block new, then tighten
Turn on blocking for new findings at the highest severity, scoped to teams that finished phase 3 cleanly. Roll it out in waves, not all at once.
| Wave | Who | Gate |
|---|---|---|
| 1 | Volunteer and platform teams | Block new critical |
| 2 | Customer facing services | Block new critical and high |
| 3 | Everyone else | Same as wave 2 |
| Later | Teams with small backlog | Add age limits on old findings |
Exceptions and the escape hatch
Every gate needs a documented way through: a time boxed exception with a named approver and an expiry. Without one, an urgent hotfix gets someone to disable the check entirely, which is worse. See what happens when a vulnerability exception expires.
Metrics for the program
- Share of repos scanned.
- Share of repos in each phase.
- Median time to fix a new high finding.
- Count of active exceptions and how many are near expiry.
- Builds blocked per week and bypass count.
Questions to ask a vendor
Can I run a gate in evaluate mode per repo? Can I scope enforcement by team group? Can the same policy be promoted from warn to block with one change that is visible in an audit log?
Safeguard supports policies, gates and guardrails for this kind of staged rollout, along with reachability analysis to cut noise; autonomous remediation fix PRs are off by default with every category on Manual.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how many findings drop out once unreachable code is set aside. That is the list you want blocking builds.
Quick check
How long should the warn phase last?
Two to four weeks per wave is typical, long enough to see real pull requests and tune noise.
Do we have to fix old findings before blocking?
No. Baseline them, schedule them separately, and block only what is introduced after the baseline.
Last reviewed: 19 October 2026.
