Chapter 52 — Registries and image security basics

In one sentence

A registry (Docker Hub being the most common default) stores and serves container images, and because ANYONE can publish to most public registries, treating every pulled image as untrusted-until-verified is a real, necessary security practice, not paranoia.

Why this matters

Pulling and running a container image is, functionally, downloading and executing someone else's code with real privileges on your machine — the same supply-chain scrutiny you'd apply to any dependency applies here.

How it actually works

   docker pull nginx                  # pulls from Docker Hub by
                                     # default (implicitly:
                                     # docker.io/library/nginx:latest)
   docker pull ghcr.io/someorg/someimage:v1.2.3   # a DIFFERENT
                                     # registry, explicitly -- GitHub
                                     # Container Registry, in this
                                     # example
   docker tag myimage myregistry.example.com/myimage:v1   # tag an
                                     # image for a specific registry
   docker push myregistry.example.com/myimage:v1     # publish it
                                     # (needs `docker login` first)

   PRACTICES WORTH ADOPTING AS DEFAULT:
     [ ] PIN images by a specific TAG (or, more strongly, by DIGEST --
         `nginx@sha256:abc123...`) rather than `latest` -- reproducible,
         and immune to the tag being silently repointed later (this
         wiki's advanced security guide covers exactly this "mutable
         tag" risk in its supply-chain chapters).
     [ ] SCAN images for known vulnerabilities before running them in
         anything beyond a quick local test -- tools like `docker
         scout`, Trivy, or Grype check an image's installed packages
         against known-CVE databases.
     [ ] PREFER official/verified publishers on public registries
         (Docker Hub marks "Official Images" and "Verified Publisher"
         images distinctly) over an unknown, unverified account's image
         claiming to be the same thing.
     [ ] for anything running in production, prefer a PRIVATE registry
         (or a pull-through proxy/mirror) you control, rather than
         pulling directly from the public internet on every deploy.

Real-world example

   Security researchers (multiple firms, including well-documented
   public research from Palo Alto Networks' Unit 42 and from Sysdig,
   among others, published across several separate studies over the
   years) have REPEATEDLY found MALICIOUS IMAGES living on Docker Hub's
   public registry -- images designed to look like legitimate,
   popular software (via names deliberately similar to well-known,
   real projects -- a "typosquatting" pattern directly analogous to the
   malicious-package problem covered in this wiki's security guides'
   supply-chain material) but actually containing CRYPTOMINING malware,
   or other unwanted payloads, that activate once the image is pulled
   and run.
   Because ANYONE can create a Docker Hub account and publish public
   images with essentially any name they choose, this is a persistent,
   REAL, ongoing risk category -- not a one-time, patched incident. The
   practical, industry-standard defence, reflected directly in this
   chapter's practice list: don't blindly `docker pull` and run
   whatever image a quick search or an unofficial-looking tutorial
   suggests; check for "Official Image"/"Verified Publisher" status,
   check the publisher's actual identity and reputation, and -- for
   anything beyond throwaway local experimentation -- scan the image
   before running it, exactly the way you'd scrutinise an unfamiliar
   third-party code dependency before adding it to a real project.

Try it yourself

# See the difference between an official image and pinning by digest
docker pull nginx:latest
docker inspect nginx:latest --format '{{.RepoDigests}}'   # the actual,
                                                          # immutable
                                                          # digest
                                                          # underneath
                                                          # the mutable
                                                          # "latest" tag

# Pull by that exact digest instead of a mutable tag (copy the digest
# from the output above)
# docker pull nginx@sha256:<the digest you saw above>

# Scan an image, if you have a scanner installed (Docker Desktop
# includes `docker scout` by default on many installs)
docker scout quickview nginx:latest 2>/dev/null || \
  echo "(docker scout not available -- try installing Trivy:
  https://aquasecurity.github.io/trivy/ for an open-source alternative)"

Common mistakes

Pulling images by latest (or any mutable tag) and trusting it stays the same. It can be silently repointed to different content later — pin by digest for anything that matters.
Assuming a popular-sounding image name is the real, official one. Typosquatting on registries is a real, documented, ongoing risk — verify the publisher.
Never scanning images before running them in anything beyond a quick, fully throwaway local test. A five-second scan is cheap insurance against a genuinely real risk category.

Check yourself

Why is pinning an image by digest stronger than pinning by tag?
What is registry typosquatting, and why does it work?
What does "Official Image"/"Verified Publisher" status on Docker Hub actually tell you?