Registries & Image Scanning
Where images live, why digests beat tags, and catching a known vulnerability before it reaches production.
The Registry Is Part Of Production
An image is layers plus a manifest, addressed by a content digest — a hash of the manifest. Tags are mutable pointers to digests, which is convenient and is why myapp:1.4.2 is not a guarantee of anything.
Tags Versus Digests
| Tag | Digest | |
|---|---|---|
| Example | myapp:1.4.2 | myapp@sha256:9f2c… |
| Mutable | Yes — can be repointed | No, by construction |
| Reproducible | Not guaranteed | Always the same bytes |
| Use for | Humans reading a changelog | Anything a machine deploys |
:latest means "whatever was pushed most recently", so two nodes pulling at different times can run different code under the same name — and the difference is invisible in every dashboard you own.# build once, tag for humans, deploy by digest
docker build -t registry.acme.io/orders:1.4.2 .
docker push registry.acme.io/orders:1.4.2
# the deploy manifest references the immutable digest
image: registry.acme.io/orders@sha256:9f2c1b7d…Set a retention policy early. Registries grow without limit, and the storage bill for six years of every CI build is a genuinely surprising line item.
Vulnerability Scanning
Scanners compare the packages in an image against vulnerability databases. Almost everything they find comes from the base image and transitive dependencies, not from code anyone on the team wrote.
| Where to scan | Catches |
|---|---|
| In CI, before push | Stops a bad image from ever existing in the registry |
| In the registry, continuously | New CVEs against images already built |
| At admission, in the cluster | Anything that slipped through both |
The practical lever is a smaller base image. Distroless or Alpine bases carry a fraction of the packages, so most findings disappear because the vulnerable package was never installed. Fail the build on critical severity, and triage the rest — a policy that fails on everything gets switched off within a fortnight.
Signing, SBOMs & Promotion
Scanning asks whether the image is vulnerable. Provenance asks a different question: is this the image we built, from the source we think, by the pipeline we trust.
| Artefact | Answers |
|---|---|
| Signature (Cosign, Notary) | Who produced this image, verifiable at admission |
| SBOM | Exactly what is inside it, for the next CVE |
| Build attestation | Which commit, which pipeline, which inputs |
| Admission policy | Refuses anything unsigned or unscanned |
An SBOM pays for itself the day a widely-used library CVE lands: instead of rebuilding and scanning everything to find out where it is, you query the SBOMs you already stored.
Interview Questions
Tag or digest for deployments?
Digest. Tags are mutable pointers, so two pulls of the same tag can produce different images; a digest is the content hash and always resolves to the same bytes.
Why is :latest dangerous?
It means whatever was pushed most recently, so nodes pulling at different times run different code under one name, and no dashboard shows the difference.
Why scan images continuously rather than once?
CVEs are published after the build. An unchanged image becomes vulnerable the day a new advisory lands, so registry-side rescanning is what catches it.
What is the most effective way to reduce findings?
A smaller base image. Distroless or Alpine bases carry far fewer packages, so most vulnerabilities disappear because the package was never present.
What does image signing give you that scanning does not?
Provenance. A signature verified at admission proves the image came from your pipeline, which scanning — a statement about contents — never establishes.
Why promote the same digest instead of rebuilding?
A rebuild produces different bytes, so production runs something that was never tested. Promoting the tested digest is what makes the pipeline meaningful.