Roll out a scanner upgrade in stages: run the new version in shadow mode beside the old one, diff the findings, canary a few repositories, then widen. Label new findings caused by the upgrade separately from findings caused by new code, so teams do not get blamed for the scanner changing.
Why upgrades cause floods
A newer scanner often detects more. It may support a new ecosystem, parse a format it skipped before, or ship updated rules. All of that is good, but if the upgrade ships to every pipeline at once, every team sees a spike in findings and a failing gate on code they did not touch. Trust in the tool drops, and exceptions get filed in bulk.
There are three sources of change after an upgrade: new detections, changed severity or rule logic, and removed detections. The third is easy to forget. A fix to a noisy rule can make findings disappear, and you want to know that was intended.
A staged rollout
- Read the release notes and note changes to analysers, rules and the database schema.
- Run the new version in shadow mode on a sample of repositories, in parallel with the current version, without gating or notifying anyone.
- Diff the output. Group differences into added, removed and changed.
- Review a sample of added findings for accuracy. If a rule produces obvious false positives, hold the upgrade or disable that rule with a documented reason.
- Canary: switch a handful of willing teams, with gates in report-only mode.
- Widen in rings, for example internal platform repositories, then one business unit, then everyone.
- Turn gates back to blocking per ring once the findings have been triaged.
| Ring | Mode | Exit condition |
|---|---|---|
| Shadow | Parallel, invisible | Diff reviewed, no accuracy surprises |
| Canary | Report only | Owners confirm findings are real |
| Early | Gate on new code only | No unexpected blocking |
| General | Normal policy | Baseline accepted |
Baselining
For the general ring, snapshot the findings that appear because of the upgrade and mark them as baseline. Gate only on findings that are new relative to that baseline, then burn the baseline down on a schedule. This keeps the pipeline moving while still giving the debt a visible owner and a date.
Keep the version of the scanner and the database in every result, so you can tell later whether a finding appeared because of code or because of the tool.
Rollback
Make the scanner version a configuration value, not something baked into hundreds of pipeline files. If an upgrade misbehaves, you should be able to revert it in one change. Rolling back also means having kept the previous version's cache and database available.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped and prioritised, which helps when a batch of new ones arrives at once.
Safeguard's policies, gates and guardrails let you choose when a finding blocks a change, which supports a report-only phase first. You can try the free scan at https://gold.safeguard.sh/scan.
Quick check
Should I wait a few weeks before adopting a new scanner version?
A short delay is reasonable for a major version. Use that time for the shadow run rather than waiting passively.
How do I explain a spike to teams?
Tag findings with the scanner version that first reported them, and tell teams that baseline findings are a tool change, not a regression.
Last reviewed: 19 October 2026.
