A base image is the image your image extends, named in the Dockerfile FROM line. A builder stage compiles code and is discarded. Scratch is an empty base. A tag is a movable label, and a digest is the fixed hash of the content. Security reviews use these words constantly, so here is each one, with why it matters.
The terms
| Term | Definition | Why a security reviewer cares |
|---|---|---|
| Base image | The image your image extends, referenced by the FROM instruction | Most operating system findings come from here |
| Parent image | Informal synonym for the base, or the one directly above yours in a chain | Chains hide who is responsible for patching |
| Builder stage | An earlier stage in a multi-stage build that compiles or packages the app | Its tools should not ship, so should not be in the SBOM |
| Scratch | A special empty base with nothing in it | Minimal, but scanners may see little inside |
| Layer | A set of filesystem changes produced by one build step | Findings and secrets can live in a layer even if later deleted |
| Tag | A human readable label such as 1.4, which can be moved to another image | Cannot prove which image you ran |
| Digest | A hash of the image content, such as sha256 followed by the value | Identifies one exact image |
| Manifest | The document listing an image's layers and configuration | What the digest actually hashes |
| Index | A manifest that points to one image per platform | Scan each platform image, not just the index |
| Registry | A server storing and serving images | Where scan and retention policy usually live |
Base image and builder stages
The Docker documentation defines a base as the image that your image extends, and notes it refers to the contents of the FROM instruction. It also describes FROM scratch as the special base for images with only what an application needs.
The multi-stage build documentation shows a second FROM starting a new stage, with COPY from the earlier stage taking only the built artifact. The build tools of the earlier stage are left behind and not saved in the final image. That is why builder stages matter less for production exposure than the final stage does. They still matter for build-system compromise, which is a different problem.
Tag versus digest
The Kubernetes documentation on images explains that if you give no tag, Kubernetes assumes latest, and that a digest consists of a hash algorithm plus a hash value. When a reference has both, only the digest is used for pulling.
The OCI image specification defines the content descriptor that carries the type, the digest and the size of referenced content. In practice, that is the mechanism that makes a digest reliable: change a byte and the digest changes.
Why it matters for answers you give customers: if a questionnaire asks "which version of the image is running", a tag is not an answer. A digest is.
Layers and why deleted content remains
Each build instruction can add a layer. A file added in one layer and removed in the next is gone from the final filesystem view, but the earlier layer still contains it. For vulnerability scanning, this means a package removed late can still appear in some scanners' layer-by-layer view. For secrets, it is worse. See a deleted secret in a later layer.
Using the terms in a questionnaire
Good answers name the thing exactly. Say "we pin base images by digest and rebuild monthly", not "we use up to date images". Say "scan results are stored by digest", not "we scan images". For more on this, see how to answer container image security questions.
Where Safeguard fits
Safeguard scans container images, produces SBOMs and applies policy by image. Try the free scan to see which base image and packages it identifies in one of yours.
Quick check
Is a tag the same as a version?
No. A tag is a label that can move. A version is a claim about the content. Only a digest identifies the exact image.
Do builder stages appear in the final image?
No, only what you copy out of them does, unless you build them as the final target.
Sources
- Docker Docs: Base images
- Docker Docs: Multi-stage builds
- Kubernetes: Images
- OCI Image Specification: Descriptor
Last reviewed: 19 October 2026.
