To find every service using a vulnerable base image, record the base image reference and digest when you build, using standard OCI annotations, then search your registries and running workloads for that digest. Without build time records you must unpack layers or guess from Dockerfiles, which is slow and unreliable.
Why this is hard after the fact
An image is built on a base, and the base is built on another base. Once the build finishes, nothing in the final image says which tag you started from unless someone wrote it down. Tags also move. The Docker documentation describes tags as labels that can be reused or changed, while a digest is a content hash that identifies exactly one image.
So "we use debian slim" is not an answer. Which digest of it, at which build time, is.
The annotations to set
The OCI image specification defines pre defined annotation keys. These are the ones that help here:
| Key | Meaning |
|---|---|
| org.opencontainers.image.base.name | Fully qualified reference of the immediate base image |
| org.opencontainers.image.base.digest | Digest of that base |
| org.opencontainers.image.revision | Source control revision of the packaged software |
| org.opencontainers.image.source | URL of the source used to build the image |
| org.opencontainers.image.version | Version of the packaged software |
The spec says the base fields should name the immediate base that supplies the layers, not other images used in a multi-stage build. Keep that in mind when you read the data back.
Steps
- Add the annotations in your build. Most image build tools can set labels or annotations; make it part of the shared pipeline template so every service gets it.
- Resolve the base to a digest at build time. Write the digest, not just the tag.
- Ask the vulnerability question by digest. When a base image gets a new advisory, list the affected base digests.
- Search registries. Find images whose base digest matches. This gives candidates.
- Cross check with what runs. Compare to image digests in each cluster or account. Running matches are urgent, registry only matches are cleanup.
- Open one change per owner. Group by the source annotation or your service catalog.
For images built before you had annotations
Fall back to layer comparison: an image built on a base shares that base's layer digests as its first layers. It is a heuristic, so treat results as leads and confirm with the build file in the source repository.
Try it yourself
Open the demo to see how an image scan lists its operating system packages and findings. Look for the base layer entries, since those are what a base image advisory touches.
Click through it at your own pace, or open it full screen.
Quick check
Is pinning the base by digest enough?
It makes builds repeatable, but it also freezes the base until you update the digest. Pair it with a routine for refreshing.
Do multi-stage builds break this?
Only the final stage's base matters for what ships. The OCI spec says the base fields should name the immediate base, not images used in earlier stages.
Safeguard's container image scanning and SBOM generation record image contents so base layer findings can be traced across services. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
