Give every rarely deployed service a scheduled rebuild that has no code changes in it: pull a fresh base, rebuild, run a smoke test, and redeploy. Monthly works for most. The trigger is the calendar, not a feature, because quiet services are exactly the ones whose images age unnoticed.
Why quiet services go stale
An image is a snapshot. Docker's own guidance says building an image captures the base image, libraries and other software at that moment, and that you should rebuild regularly to keep them updated. A service that nobody touches never gets that rebuild, so its image drifts further from current with every week.
The usual causes are plain. No team member has it on a roadmap. The pipeline only runs on commit. The person who knew how to deploy it left. Nothing is broken, so nobody looks.
The scheduled rebuild, step by step
- Find the quiet services. Sort your image register or registry by last build date and list anything older than your threshold, say sixty days.
- Add a scheduled pipeline run to each repository, separate from commit triggers. A calendar based trigger is available in most CI systems.
- In the build, pull the base fresh. Docker documents a flag for exactly this, the pull flag of the build command, which checks for a newer base even if a cached one exists.
- Run a smoke test: start the container, hit a health endpoint, and run one real request path.
- Deploy only if the smoke test passes. If it fails, open a ticket for the owner instead of deploying.
- Record the build date and the base digest.
What the smoke test needs
Keep it small. The aim is to catch a base update that broke startup, not to retest the application. A container that starts, listens, and answers one request tells you most of what you need. If the service has no tests at all, writing this one is the first useful piece of work.
Picking the cadence
| Service type | Suggested rebuild rhythm |
|---|---|
| Internet facing, quiet | Every two to four weeks |
| Internal, quiet | Monthly |
| Batch job that runs rarely | Before each scheduled run, or monthly |
| Retired but still running | Plan its shutdown instead |
These are starting points to adapt, not standards. The reasoning is that exposure sets urgency.
When the rebuild keeps failing
A repeated failure is useful information. It usually means the service depends on something that disappeared, or the base moved in a way the app cannot handle. Either way, you have found a service that needs an owner decision: invest, freeze behind tighter controls, or retire.
Evidence that it happens
Keep the pipeline run history and the resulting SBOM per build. That record shows a reviewer the service was refreshed on schedule even though no code changed.
Where Safeguard fits
Safeguard's per image SBOMs and continuous monitoring show which images are old and which findings affect them, so quiet services stand out in a list. Policies can flag images past an age you choose. The free scan at https://gold.safeguard.sh/scan covers one image.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how findings appear on an asset that did not change, which is what happens to quiet services.
Quick check
Does a no code rebuild change behaviour?
It can, because the base and unpinned packages may update. That is why the smoke test exists. Pinning the base by digest and refreshing it on schedule makes each change visible.
Is monthly too often?
For most teams it is a reasonable rhythm. If the pipeline is cheap and the smoke test is reliable, weekly is fine. If rebuilds are painful, fix the pain, not the cadence.
Sources
Last reviewed: 19 October 2026.
