Show four things: a written rebuild standard, pipeline run history that follows it, the base image digest for each build, and an SBOM per build. Together they let a reviewer pick any date and see what was built, what it contained, and whether the schedule held.
The standard comes first
A cadence you can only describe verbally is hard to evidence. Write it down in a short document. It should say how often images are rebuilt, who owns the schedule, what happens when a rebuild fails, and when exceptions are allowed. Version the document and keep its review date current.
Avoid promising more than you do. "Production images are rebuilt at least monthly" is better than "always up to date", because the first can be checked.
Four pieces of evidence
| Evidence | What it proves | Where it lives |
|---|---|---|
| Standard | The rule exists and was approved | Policy repository |
| Pipeline run history | Rebuilds happened on dates | CI system or registry |
| Base digests per build | The base was actually refreshed | Build logs, image annotations |
| SBOM per build | What the image contained at that time | Registry or artifact store |
The base digest is the one teams forget. Without it, a rebuild that quietly reused a cached base looks identical to a real refresh. Docker's guidance notes that a pull flag exists to force a fresh base, and that a no cache build is a separate thing. If the digest changed between builds, the refresh happened.
Make the evidence retrievable
Reviewers sample. They pick a service and a date and ask to see it. Test yourself first.
- Pick three services at random.
- For each, find the last two rebuild dates and confirm the gap fits your standard.
- Retrieve the SBOM and base digest for each.
- Time how long it took. If it took hours, automate the lookup.
Handling the gaps
Some images will miss the schedule. That is normal. What reviewers look for is whether you knew. Keep an exception list with owner, reason and end date, and show that gaps are tracked and closed. An open exception from last year with no activity is worse than the original miss.
Retention
Keep records for as long as your own policy and contracts need. How long that is should come from your auditor or contracts, not from a blog. Store the evidence somewhere that survives a pipeline migration.
Do not stage a screenshot
Prefer machine generated records over screenshots. A pipeline run URL and an SBOM file are verifiable. A screenshot of a dashboard is not, and it will not match next time you look.
Where Safeguard fits
Safeguard's compliance and evidence automation collects per image scan and SBOM records over time, so you can answer date based questions without a manual hunt. We do not claim any certification, and what an auditor accepts is for the auditor to decide.
Quick check
Is a calendar reminder enough evidence?
No. It shows intent, not outcome. The run history and base digests show outcome.
What if a rebuild failed and we skipped a month?
Record it as an exception with the cause and the date it was fixed. Showing you noticed and acted is what matters.
Sources
Last reviewed: 19 October 2026.
