Do not try to fix the first scan. Record it as a baseline, block only findings that are new or worse than the baseline, and tighten the threshold on a fixed schedule. This turns an overwhelming list into a ratchet: things can only get better, and nobody is asked to clear years of debt before shipping.
Why the first scan is always ugly
Registries collect images for years. Many were built from base images that have since gained dozens of advisories, and nobody has looked. A first scan will count findings in the thousands for a modest number of repositories. That number is a fact about history, not about your team today.
Two bad reactions follow. One is to ignore the report. The other is to turn on a blocking gate, break every pipeline in a day, and turn it off a day later. A baseline avoids both.
Four phases
| Phase | Goal | Gate action |
|---|---|---|
| 1. Inventory | Know what runs and who owns it | None |
| 2. Baseline | Snapshot findings per deployable image | None, report only |
| 3. Ratchet | Block new criticals and regressions | Block on new, warn on old |
| 4. Tighten | Lower the allowed baseline on a schedule | Block on shrinking set |
Phase 1: inventory
Scope first. Most registry content is not deployed. List what runs, tie it to owners, and set the rest aside for cleanup. See which image tags in a registry should you scan and list every container image running in your cluster.
Phase 2: baseline
Run the scan against the deployable set and save the findings, keyed by image digest and finding. This file is your baseline. Do not argue about individual items yet. The baseline is accepted debt with a clear date on it.
A related approach for other scanner types appears in baseline a new scanner without a finding flood.
Phase 3: ratchet
Now configure the gate: fail a build if it introduces a finding not in the baseline, or a finding of higher severity than the baseline allows for that service. Findings in the baseline produce warnings only. Developers feel the control only when they make things worse, which is fair.
Three rules keep it honest:
- New images start with an empty baseline.
- Rebuilding on a newer base can only remove baseline entries, never add them.
- Baseline entries carry an expiry date.
Phase 4: tighten
Pick a rhythm. Each month, pick the highest-value slice and move it from baseline to enforced: critical findings with a fix available first, then high, then findings in internet-facing services. Publish the schedule so teams can plan the work. Quick wins come from rebuilding on a patched base, since that clears many findings at once. See container scan shows hundreds of vulnerabilities, what to do first.
Measure progress
Track the baseline size over time and the count of baseline entries past their expiry. A baseline that shrinks proves the programme works. One that never changes tells you the ratchet is cosmetic.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are grouped and prioritised, which is the view you want for phase 2.
Where Safeguard fits
Safeguard supports policies and gates and dependency scanning across images, so a gate can act on new findings only. Start with a free scan.
Quick check
Is a baseline just hiding problems?
Not if it has an owner, an expiry date and a tightening schedule. It records known debt and stops new debt from forming.
How long should phase 2 take?
Usually days, not months. The aim is a snapshot, not a clean-up.
Last reviewed: 19 October 2026.
