Compare the scan of the new image digest against the scan of the last released digest and sort findings into new, fixed and unchanged. Review the new ones, confirm the fixed ones, and check that unchanged ones still have an owner and a date. This is faster and more honest than rereading the whole list.
Why a diff beats a full read
A full report is long and mostly familiar. Reviewers skim, and a new critical finding hides among old ones. A diff puts attention on change, which is what a release is. It also shows progress, since the fixed list is evidence of work done.
Set up the comparison
Keep both scans against digests, not tags, so you compare content. If the last release's digest is not recorded, record it from now on. Scan results change over time as advisories are published, so rescan the old digest today as well. Otherwise the diff mixes image changes with data changes. See why an unchanged image gains vulnerabilities.
| Comparison | Answers |
|---|---|
| Old digest rescanned today vs new digest scanned today | What did our changes do? |
| Old digest scanned at release vs old digest scanned today | What did new advisories add? |
| Old digest at release vs new digest today | Mixed, hard to interpret |
Use the first row for the release decision.
Sort into three groups
- New: present now, absent before. Cause is either a new package, a new version with a new flaw, or a newly matched advisory. Review each.
- Fixed: absent now, present before. Confirm the installed version moved. See confirming a fix landed.
- Unchanged: present in both. Check each has an owner, an expiry or a plan.
Read package changes too
A finding diff does not show why. A package diff does: which packages were added, removed or changed. A base image bump might add dozens of package updates. See reading an SBOM diff.
Release rules to adopt
- Block on new findings above a threshold you set, such as reachable critical findings with a fix.
- Allow unchanged findings that have a current exception.
- Require evidence for fixed ones.
- Record the decision with both digests.
For gates, see what a policy gate should block.
A small record
Release: 2026-10-19
Old digest: sha256:aaa... New digest: sha256:bbb...
New: 3 (2 reviewed, 1 exception)
Fixed: 12
Unchanged: 8 (all with owner and expiry)
Decision: approved by <name>
Where Safeguard fits
Safeguard's SBOM and dependency scanning supports comparing component data between builds, and policies and gates can enforce release rules. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate reacts to new findings.
Handling a large diff
A base image bump can produce a long new list and a long fixed list at once, because many packages change. Do not read it row by row. Group the new findings by package and look at the top few groups. Often one package update brought several rows, and the cause is a single changed dependency.
Check the severity and reachability of the new group first. A hundred new low rows matter less than one new reachable critical. Set a rule in advance for how many new findings of each level can ship without review, so the decision does not depend on who is on call.
Keeping the baseline honest
The baseline for the next release is the scan of the digest you just shipped, taken on release day. Store it with the release record. If you store just the report from months ago, the next diff will show advisories as new findings in your own change. A fresh baseline per release keeps the comparison fair and the discussion short.
Quick check
Do I need to rescan the old digest?
Yes, if you want to isolate your change from new advisory data. Otherwise the diff mixes both.
Should unchanged findings block a release?
Not if each has a current exception or plan. Blocking on them stalls every release for old issues.
Last reviewed: 19 October 2026.
