A container tag is a name that can point to different image content over time. A digest identifies specific content. Pinning a digest makes the selected base image explicit, but it also means a rebuilt application will keep using that image until the reference is changed.
Reproducible selection and timely patching are separate requirements. A deployment process needs to satisfy both by recording what it uses and providing a reviewed path for replacing it.
Know which image the build selected
Docker's build guidance explains that tags are mutable and that digest pinning fixes the image content used by a build. It also discusses the need to update pinned references when adopting newer base images. Docker's build practices describe this tradeoff.
In an illustrative web service, the application source has not changed, but a base operating-system package requires an update. Rebuilding against the same pinned digest may reproduce the older package. The source-code revision alone does not identify whether the relevant component changed.
Follow the patch through each artifact
Record the old base digest, replacement base digest, resulting application-image digest, and deployment revision. Check the final image's contents rather than assuming the updated base remains unchanged through later build steps. Additional package installation can reintroduce versions or add components outside the base image.
The running fleet also matters. A registry containing a patched image does not establish that every workload has pulled and started it. Long-running workers, regional deployments, and rollback configurations can retain older images after the main service has been updated.
Treat rebuilding as a tested change
Run the application's relevant checks against the rebuilt image. Changes to system libraries, certificate stores, or language runtimes can affect behavior even when application source is identical. Include a deployment health check and the business function associated with the service.
If the update fails, record the rollback decision and the remaining exposure rather than silently marking the vulnerability resolved. The remediation state should follow the deployed artifact, not the existence of a successful build job.
Verify the running digest
An assessment can select a sample service and trace its declared image to the actual running digest. Compare that digest with the reviewed release and component inventory. Repeat after a rollout and a controlled rollback to identify which evidence remains available for both states.
The business receives a specific patch record: which image changed, which workloads were updated, which checks passed, and which older instances remain. This supports incident response and maintenance planning. It also prevents a digest-pinning policy from being mistaken for an automatic update mechanism.
Sources
Kubernetes: Images. The web-service update is illustrative, and rollout behavior depends on the deployment platform.
