Cybersecurity glossary
What is a Container Image?
Learn what a container image is, how layers and digests work, why tags are not trust, and which image hygiene choices reduce runtime and supply-chain risk.
Definition
A container image is an immutable, layered filesystem snapshot plus metadata (entrypoint, environment, user, architecture) that a runtime unpacks to create a container. It is identified by a content digest, not by a moving tag.
Why container images matter
Every Kubernetes pod, serverless container, and CI job starts from an image. If that artifact is bloated, unsigned, or built from an untrusted base, the cluster inherits those problems at scale.
A container image is not “the app in a VM.” It is a content-addressed filesystem plus a config blob. Understanding layers, tags, and digests is how you stop deploying yesterday’s malware under today’s :latest.
From build to running container
A build produces layers
Each instruction adds a filesystem diff. Multi-stage builds can throw away compilers and keep only the runtime.
A manifest lists the bits
The image index points at architecture-specific manifests, configs, and layer digests.
The registry stores the artifact
Push uploads layers that the registry can deduplicate. Authn and policy decide who may read or overwrite tags.
A node pulls by tag or digest
The runtime fetches missing layers, verifies digests, and unpacks a rootfs.
A container starts from the snapshot
The process gets the image user, env, and entrypoint, plus any runtime mounts and secrets.
Image identity: tags versus digests
Tags are labels
:latest, :v1, and :prod can be moved to a different digest without changing the name.
Digests are hashes
sha256 pins the exact manifest. Two pulls of the same digest should yield the same content.
Signatures bind identity
Cosign or similar attestations say who built which digest, not which tag string.
SBOMs describe contents
A package list for that digest makes CVE triage possible without guessing the base OS.
Image design choices that affect security
| Choice | Safer default | Why it matters |
|---|---|---|
| Base image | Minimal or distroless, from a signed internal cache | Fewer packages mean fewer CVEs and a smaller attack toolkit |
| User in the image | Non-root USER instruction | Running as UID 0 inside the container makes host mapping mistakes worse |
| Secrets at build time | Never COPY .env or bake tokens into layers | Deleted files can remain in older layers and in the registry |
| Tagging strategy | Immutable tags plus digest pins in production manifests | Moving tags make incident response and rollbacks guesswork |
| Provenance | Signed build attestations from a trusted pipeline | A pretty Dockerfile in git is not proof of what was pushed |
Container image hygiene checklist
- Build from a small, internally mirrored base; do not pull anonymous :latest from the public internet in CI.
- Use multi-stage builds so compilers, tests, and SSH keys never land in the final layers.
- Set a non-root USER and a read-only-friendly filesystem layout in the image itself.
- Pin production deployments to digests; treat tags as human-readable aliases only.
- Sign images and verify signatures at admission time before they can run.
- Attach an SBOM to each digest and scan that digest, not an unrelated tag.
- Delete unused tags and old digests on a retention policy so leaked secrets in old layers expire.
- Keep secrets out of Dockerfiles, build args that become labels, and layer history.
The practical takeaway
A container image is an immutable, digest-addressed snapshot that runtimes turn into processes. Tags are nicknames; digests and signatures are identity.
Build small, run as non-root, never bake secrets, and deploy by digest from a registry you control. The image is the software you actually ship—treat it with the same review you give source.
Related security terms
Container Image Scanning
Automated review of image contents for known vulnerabilities and secrets.
Image Registry
The store that hosts, authenticates, and distributes images.
Container Runtime
The node software that pulls an image and starts a container from it.
Software Supply Chain Attack
Images are a high-value distribution channel for poisoned software.
Reproducible Build
A way to prove an image’s bits match the intended source and toolchain.
Frequently asked questions
What is a container image in simple terms?
It is a packaged snapshot of files and startup settings. The runtime copies that snapshot into an isolated process. The snapshot is the image; the running process is the container.
What is the difference between a tag and a digest?
A tag such as :latest is a movable pointer. A digest (sha256:…) is a hash of the image contents. Deploy and pin by digest when you need the same bits tomorrow.
What is a base image?
The first layers your Dockerfile or build starts from, such as a distro or distroless runtime. Its packages, user, and CVE history become part of every child image.
Are images encrypted by default?
No. Registries usually protect transport with TLS, but image layers at rest need registry encryption, private repos, and signed provenance if confidentiality or integrity matter.
Why do images keep growing?
Each RUN, COPY, and package install can add a layer. Unused compilers, shells, and caches remain unless you use multi-stage builds and minimal bases.
Can two tags point to the same image?
Yes. Tags are aliases. Security reviews should treat digest identity as the source of truth, then see which tags currently point at it.
What metadata travels with an image?
Config includes user, env vars, ports, entrypoint, labels, and sometimes build attestations or SBOMs stored as related OCI artifacts.
References
Explore authoritative guidance and frameworks related to container image.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.