A base image fix passes through three clocks: the publisher releases it, you rebuild on top of it, and you deploy the result. Teams usually only measure the whole. Measuring each stage separately shows where days are lost, and the answer is more often your rebuild or deploy than the publisher.
The three clocks
| Clock | Starts | Stops | Who controls it |
|---|---|---|---|
| Upstream | Fix is available in the package source | Publisher's image carries it | Publisher |
| Rebuild | Updated base is available | Your image is rebuilt and passes tests | You |
| Deploy | Rebuilt image passes tests | It is running in production | You |
You cannot speed up the first clock, but you can see it. You own the other two.
Why the split matters
Imagine a fix lands upstream on Monday, and your service runs the fixed image on day nineteen. If you only record "nineteen days", you may blame the publisher. If you record the clocks, you might find upstream took two days, your rebuild waited eleven days for the monthly schedule, and deployment took six because of a release window. Now you know what to change.
How to measure each clock
- Upstream: note the date the advisory shows a fixed package version, and the date the base image tag or digest first contains it. Your scan or SBOM diff of the base shows when the package version changed.
- Rebuild: from that date, find the first build of your image with the new base digest. Your pipeline history and the base digest record give you this.
- Deploy: find when that digest first ran in production, from your deployment records.
You need the base digest recorded per build, which is the main reason to capture it.
Ways to shorten each clock
Upstream: not under your control, but you can know where a fix is not coming. Docker's guidance notes that a publisher updates tags to carry patches, and whether a particular package gets timely fixes depends on the distribution. If a package has limited security support, build it yourself.
Rebuild: replace a purely monthly schedule with a trigger on base changes plus the schedule as a backstop. Keep tests quick enough that the rebuild is not the slow part.
Deploy: make the rollout of a rebuilt image routine. If every rebuild needs a special approval, you have built the delay into your process.
Set a target for the clocks you own
Pick a number for your rebuild and deploy clocks together, by severity or by exposure, and publish it. For example, you might say internet facing services rebuild and deploy within an agreed number of days of an applicable fix. The exact numbers are yours to choose.
What this does not cover
If the finding sits in your application code or in a library you bundled, the base image clock does not apply. Separate those queues, because their owners and fixes differ.
Where Safeguard fits
Safeguard's per image SBOMs and continuous monitoring show when a finding first appeared, which fixed versions exist, and which images still run affected versions, so each clock has a date attached. Its fix pull requests are off by default and every category starts on Manual.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding with a fix available is separated from one with none, which is the first clock.
Quick check
Should I wait for the publisher before rebuilding?
Rebuild when the base contains the fix. Checking the base digest or its package list tells you when that is.
What if the base never gets the fix?
Then upstream is the blocker. Options include moving to a supported release, switching variant, or building the affected component yourself.
Sources
Last reviewed: 19 October 2026.
