Use a calendar schedule as the backstop, a base digest change as the main trigger, and an advisory match for urgent cases. Each catches something the others miss, and together they give you fresh images without rebuilding for no reason.
The three triggers
| Trigger | Fires when | Strength | Weakness |
|---|---|---|---|
| Schedule | A set date arrives | Simple, predictable, catches quiet services | Rebuilds when nothing changed, waits when something did |
| Base digest change | The publisher's tag points to new content | Rebuilds when there is something new | Needs a watcher, and says nothing about severity |
| Advisory match | A new finding affects a package in your image | Targeted and urgent | Needs inventory data, and only covers known issues |
Schedule
A calendar trigger is the easiest to run and the easiest to evidence. Docker's guidance says to rebuild regularly because building captures the base and libraries at that moment. A schedule guarantees that happens even if no one is watching.
The weakness is mismatch. A monthly schedule can rebuild a day before nothing changes, or sit idle for three weeks while a fix is available. Treat it as a floor.
Base digest change
A base image tag is a pointer the publisher moves. Docker notes that publishers update tags to carry newer versions and patches. A watcher that checks the digest behind your tag, and starts a rebuild when it changes, makes your image follow the base closely.
Some changes will be irrelevant to you, such as a package your image never uses. The rebuild is cheap, and automation makes the noise tolerable. Pair this trigger with tests that gate deployment.
Advisory match
An advisory trigger depends on inventory. If you hold an SBOM for each image, a new advisory can be matched to the images that contain the affected package version, and only those need action. This is the most precise trigger and the one tied to risk.
It only knows what is published. An issue with no advisory yet is invisible to it, and a package missing from the SBOM is invisible too. That is why the other two stay.
How they fit together
- Schedule: every service gets a rebuild at least every month or on your chosen rhythm.
- Digest change: services on watched bases rebuild when the base moves, with tests gating the deploy.
- Advisory match: urgent findings on running images open a priority rebuild with a named owner.
When two triggers fire close together, the pipeline should coalesce them into one rebuild instead of stacking.
Guardrails for any trigger
Automated rebuilds need limits. Require tests before deploy, keep a rollback to the previous digest, and cap how many services can roll at once. Record each trigger type in the build metadata so you can later see which one produced which rebuild.
Which to build first
If you have nothing, start with the schedule, since it is quick. Add the digest watcher next, because pinned digests make it natural. Add advisory matching when you have an SBOM per image.
Where Safeguard fits
Safeguard's SBOMs and continuous monitoring provide the advisory match, and its policies and gates can hold a deployment that fails your thresholds. Autonomous fix pull requests are off by default, with every category on Manual. The free scan at https://gold.safeguard.sh/scan shows one image.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a new advisory reaches an asset that has not changed, which is the advisory trigger.
Quick check
Is a schedule alone enough?
For low risk services it can be. For anything exposed, add a base change or advisory trigger so urgent fixes do not wait for the date.
Do automated rebuilds need human review?
Tests and gates can replace review for routine refreshes. Keep human review for release changes and for anything the tests do not cover.
Sources
Last reviewed: 19 October 2026.
