A containerised service has three patch layers: the host that runs the containers, the base image inside them, and the application dependencies on top. Each has a different fix path and a different owner. A clean result in one layer says nothing about the other two.
The three layers
| Layer | What lives here | Fix | Typical trigger |
|---|---|---|---|
| Host | Kernel, container runtime, node agents | OS update, node replacement | Vendor update cycle |
| Image | Distribution packages, language runtime | Rebuild from a newer base | Base image update, advisory |
| Application | Libraries from the lockfile | Dependency update, rebuild | Alert, update bot |
A vulnerability in one layer is not fixed by working on another. Patching the host does not change a package baked into an image. Rebuilding an image does not update a library pinned in the lockfile.
The image layer is the one people forget
Docker's build guidance says to rebuild images regularly with updated dependencies. It explains that --pull forces a check for a newer base image, while --no-cache rebuilds all layers to fetch newer packages but does not pull a fresh base image. Using both together refreshes everything. The same page notes that pinning a base image digest guarantees the same image but means you are opting out of automated security fixes, so pair pinning with a bot that proposes new digests.
More detail: rebuild container images regularly.
A practical routine
- Weekly image rebuild. Scheduled build with
--pull, run tests, push a new tag. - Update bot for the lockfile. Pull requests reviewed in the normal flow.
- Node replacement cycle. Replace hosts from a newer image instead of patching in place, where your platform allows.
- One scan per layer. Host or node scan, image scan, dependency scan.
- One view. Combine results by service, so an owner sees all three together.
Reading the results
When a scanner reports a finding, first ask which layer it belongs to. The package path and file location usually tell you. A path under the language package folder is an application finding. A path under the system library folders is an image or host finding.
Try it yourself
Click through it at your own pace, or open it full screen. Look for findings that come from the base image rather than the application.
Where Safeguard fits
Safeguard covers container image scanning and application dependency scanning, plus asset discovery to find what is running. Related: roll out a patched base image across many services.
Quick check
Do I need to patch the host if I rebuild images?
Yes. The host kernel and container runtime sit outside the image and are patched separately.
Is pinning an image digest bad for security?
Not by itself. It prevents silent changes, but you must update the pin on purpose, ideally through a bot.
Sources
Last reviewed: 19 October 2026.
