17.1.3.1 Trusted Base Practice

Trusted base practice concerns the deliberate evaluation of who actually publishes and maintains a base image before adopting it, a distinct concern from how that image is referenced and pinned, since even a perfectly digest-pinned, signature-verified image provides no protection if the underlying source itself is poorly maintained, abandoned, or, in the worst case, deliberately malicious from the outset.

Official images versus community-published ones

Docker Hub distinguishes official images, vetted and maintained through a structured program with defined security and update practices, from images published by independent, individual accounts, and this distinction matters considerably when deciding how much trust to extend to a given base image by default:

docker pull node
docker pull someusername/node-custom

The first pulls from the official node repository, maintained under Docker's official images program with defined update and security response practices; the second pulls from an individual's personal namespace, which may be entirely legitimate and well-maintained, or may not be, with no equivalent structured oversight backing it either way.

Evaluating an unfamiliar publisher before adopting their image

For any image not published under the official images program, reviewing the publisher's actual track record, how recently the image was updated, how it responds to disclosed vulnerabilities, whether its Dockerfile source is publicly available for inspection, provides a meaningful basis for trust beyond simply assuming legitimacy:

docker pull someorg/specialized-tool:latest

Checking the publisher's repository page directly for a linked source repository, recent commit activity, and any documented security policy is a reasonable, concrete due diligence step before incorporating an unfamiliar third-party image into a production build, rather than adopting it purely because it happens to provide a convenient, ready-made solution to an immediate need.

Verified Publisher and Sponsored OSS programs

Docker Hub's Verified Publisher and Sponsored Open Source programs provide an additional, though distinct, layer of identity confirmation, verifying that a given namespace is genuinely controlled by the organization it claims to represent, which addresses a different concern than the official images program's deeper maintenance and security vetting:

docker search --filter is-official=true node

A verified publisher badge confirms identity, that this is genuinely the organization it claims to be, rather than an impersonating or typosquatted account, which is a meaningful but narrower guarantee than the official images program's broader maintenance and security review.

Avoiding typosquatted image names

A deliberately similar-looking image name, differing from a legitimate, well-known image by a subtle typo or character substitution, is a known supply chain attack vector, and verifying the exact, correct spelling and namespace of an intended base image before referencing it in a Dockerfile is a simple but genuinely important safeguard:

FROM nginx:latest

FROM nginnx:latest

The second example, differing by a single repeated character, could plausibly be an entirely different, unrelated, and potentially malicious image masquerading as the legitimate, well-known nginx image to anyone who does not look closely; double-checking image references against an authoritative source, rather than typing from memory or copying from an unverified, informal example, avoids this risk.

Using an internal registry mirror for trusted bases

For organizations with stricter supply chain requirements, mirroring approved, vetted base images into an internal, controlled registry, and requiring all internal builds to reference that internal mirror rather than pulling directly from a public registry, provides centralized control over exactly which base images are actually trusted and available for use:

docker pull node:20
docker tag node:20 internal-registry.example.com/approved/node:20
docker push internal-registry.example.com/approved/node:20

FROM internal-registry.example.com/approved/node:20

This pattern also provides a single point of control for applying organization-wide policy, vulnerability scanning, signature verification, approval workflows, before an image becomes available for any internal team to actually build against, rather than relying on every individual team to perform this evaluation independently and consistently.

Provenance attestations beyond signature verification

Beyond a basic cryptographic signature confirming an image has not been tampered with, a full provenance attestation, following a framework such as SLSA, can document the actual build process itself, what source commit, what build environment, what specific steps, produced a given image, providing considerably more detailed, verifiable supply chain transparency:

docker buildx build --provenance=true -t my-api .

docker buildx imagetools inspect my-api --format '{{ json .Provenance }}'

For organizations with strict supply chain security requirements, requiring and verifying this kind of detailed provenance attestation, not just a basic signature, provides meaningfully stronger assurance about exactly how a given image actually came to exist.

Periodically re-evaluating trust in long-standing base image choices

Trust evaluated once at the time a base image was first adopted can become stale if that publisher's maintenance practices change, ownership transfers, or a previously active project becomes abandoned; periodically revisiting the trust basis for long-standing base image dependencies, not just newly adopted ones, catches this kind of drift:

docker pull node:20
docker inspect node:20 --format '{{.Created}}'

A base image that has not been updated in an unusually long time relative to its publisher's historical update cadence is worth investigating directly, since it may indicate the image has been abandoned or the project behind it has become inactive, which changes the trust calculus considerably from when it was first adopted.

Common mistakes

• Treating every Docker Hub image as equally trustworthy regardless of whether it is published under the official images program, a verified publisher, or an unverified, individual account.
• Adopting an unfamiliar third-party base image without reviewing the publisher's actual maintenance track record and security response practices.
• Not verifying an image reference's exact spelling and namespace carefully, risking an accidental or deliberate typosquatting substitution.
• Pulling directly from public registries without any centralized, internal mirroring and approval process for organizations with stricter supply chain requirements.
• Evaluating trust in a base image only once at initial adoption, without periodically revisiting whether that trust basis still holds as the publisher's own practices and activity may have changed over time.

Trusted base practice addresses a layer of supply chain security that digest pinning and signature verification alone do not cover, who actually publishes and maintains the underlying content, and requires deliberate evaluation of publisher identity and track record, careful attention to exact image naming, and, for organizations with stricter requirements, centralized mirroring and provenance attestation to maintain genuine, ongoing confidence in the base images a project's entire build foundation depends on.