When you adopt a new scanner, snapshot every existing finding as a baseline, block only on findings introduced after that date, and schedule the old ones as a separate, time-boxed backlog. This keeps day one calm and still stops the problem from growing.
Why the first scan looks terrible
A new tool reads your code with fresh eyes, so it reports everything accumulated over years. Developers see hundreds of items, learn to ignore the tool and the rollout is damaged before it starts. That reaction is predictable, so plan for it.
The four step method
- Run in report-only mode. For one to two weeks, scan on every pull request and on the main branch but do not fail builds. Nobody is blocked while you learn.
- Record the baseline. Export or tag all current findings as pre-existing. Store the date and the tool version, because later changes in advisory data will shift numbers.
- Gate on new findings only. A pull request fails only if it adds a high severity issue that is not in the baseline. That is a rule developers can accept: you broke it, you fix it.
- Burn down the baseline on a calendar. Group old findings by service and severity, give each group an owner and a target date, and report progress weekly.
Pitfalls
- Baseline drift. If a dependency is upgraded and the same vulnerable package returns in a new form, your baseline match may treat it as new or old incorrectly. Decide how matching works, usually by package, version and advisory ID.
- Hidden baselines. A baseline file nobody reviews becomes an amnesty. Put an expiry date on it and review it every quarter.
- Severity inflation. Do not gate on medium findings at launch. Start with critical and high, then tighten.
- Comparing counts across tools. The new scanner will not match the old one. See why two scanners report different counts.
Who to tell and when
Tell developers before the first scan, not after. A short note covering what the tool does, what it will not block yet, where to see results and who to ask for help is enough. Name an owner for questions. If the first message from the scanner is a failed build, you will spend weeks recovering trust.
When to tighten
Move to a stricter gate once the baseline is under control and false positives are rare. A common order is: report only, block critical new findings, block high new findings, then add policy checks such as license rules.
Where Safeguard fits: its policies, gates and guardrails let you set blocking rules per category, and you can try the same approach on a public repo with the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what makes a pull request pass or fail, and picture the rule applying only to new findings.
Quick check
Should the baseline ever be deleted?
Only when the findings in it are fixed or formally accepted. Set an expiry so it cannot become a permanent exception.
Last reviewed: 19 October 2026.
