Supply Chain Security for Docker Base Images

1. Why the base image supply chain is a risk of its own

Supply chain security for Docker base images addresses an attack surface that starts long before your own code: a base image like `node:20-alpine` is built and maintained by a third party and published to a registry that your team implicitly trusts the moment it references the image by tag. If that base image is compromised, for example through an attack on the maintainer's build pipeline, every image built on top of it automatically inherits the compromise.

Real incidents such as the `ua-parser-js` attack or compromised Docker Hub accounts show that this supply chain is not a theoretical risk. Supply chain security in Docker environments concretely means making every step, from choosing a base image to shipping the finished image, verifiable, instead of following implicit trust in tags and registry names. The following sections show how to implement this traceability with concrete tools available today.

2. Digests instead of tags: reproducible references

A tag like `node:20-alpine` is a mutable reference that the maintainer can redirect to a different, new image at any time, without the tag name changing. For supply chain security this is a problem: a build that pulls `node:20-alpine` today can get a different image tomorrow without the Dockerfile ever changing. A content digest like `node@sha256:8f3c...`, on the other hand, references exactly one immutable content, cryptographically guaranteed by the SHA256 hash of the image manifest file.

Pinning to digests instead of tags is the simplest and most effective single step for supply chain security, because it requires no additional infrastructure, only discipline in maintaining the Dockerfile. The downside is obvious: digests are not human readable and must be explicitly updated on every base image update. Tools like Dependabot or Renovate automate exactly this update step and open a pull request as soon as a new, verified digest is available.

# Dockerfile: pin the base image to an immutable content digest, not a mutable tag
FROM node@sha256:8f3c1a9b2e77d4f6c0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3

# Resolve the current digest for a tag before pinning it
# docker pull node:20-alpine
# docker inspect node:20-alpine | jq -r '.[0].RepoDigests[0]'

3. Checking trusted registries and provenance

Not every registry offers the same security level. Docker Hub allows any registered user to publish images under their own namespace, and name confusion attacks like `libary/node` instead of `library/node` are a known attack pattern that relies on developer typos. Supply chain security therefore starts with a deliberate choice of source: official Docker Official Images, verified publisher images, or a private, curated registry, instead of arbitrary community images without provenance.

For organizations with higher requirements, an internal registry with a curated allowlist of approved base images is worthwhile, combined with an admission policy that technically prevents pulls from unapproved external sources. This approach shifts supply chain security from a matter of individual developer discipline to an enforced organizational policy.

4. Introducing image signing with Cosign

Cosign, a project from the Sigstore ecosystem, cryptographically signs Docker images and stores the signature directly alongside the image in the registry. Unlike classic PKI based signing schemes, Cosign also supports keyless signing via short lived certificates bound to an OIDC identity such as a GitHub Actions workflow, instead of requiring a long lived private key to be managed manually. For supply chain security, this considerably lowers the operational barrier, because no key management process is needed for individual developers.

The signature confirms two things: that the image has not been altered since signing, and that it comes from a specific, verifiable identity. Both properties are decisive for supply chain security, because they make subsequent tampering in the registry, for example through a compromised registry account, technically detectable instead of relying on pure trust.

#!/usr/bin/env bash
# Sign an image with Cosign using keyless (OIDC-based) signing
set -euo pipefail

cosign sign --yes \
  myregistry.example.com/shop-api@sha256:8f3c1a9b2e77d4f6c0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3

# Alternative: sign with a locally managed key pair
cosign generate-key-pair
cosign sign --key cosign.key \
  myregistry.example.com/shop-api@sha256:8f3c1a9b2e77d4f6c0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3

5. Verifying signatures at pull and deployment time

A signature alone brings no security benefit as long as nobody checks it. The second necessary step for supply chain security is to enforce verification at the point where an image actually runs in production, whether at pull time on the build server or as an admission policy in the orchestrator. Without this enforced check, signing remains a pure formality with no technical effect.

Cosign offers a verification command that returns a non zero exit code when a signature is missing or invalid, which integrates directly into CI gates. In Kubernetes environments, tools like Kyverno or the Sigstore Policy Controller take on this enforcement as an admission webhook, so unsigned images never even start.

#!/usr/bin/env bash
# CI gate: refuse to deploy an image without a valid Cosign signature
set -euo pipefail

IMAGE="myregistry.example.com/shop-api@sha256:8f3c1a9b2e77d4f6c0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3"

if ! cosign verify --certificate-identity-regexp "https://github.com/mironsoft/.*" \
     --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
     "$IMAGE" > /dev/null 2>&1; then
  echo "[BLOCKED] Image signature verification failed, refusing to deploy" >&2
  exit 1
fi

echo "[OK] Signature verified, proceeding with deployment"

6. Understanding provenance attestations under SLSA

A signature confirms who signed an image, but not how it was built. This is exactly the gap that SLSA (Supply-chain Levels for Software Artifacts) closes with provenance attestations: a structured statement about which build process, which source repository, and which commit produced an image. For supply chain security, this is an important additional building block, because it prevents an attacker with stolen signing credentials from signing a tampered image in the name of the legitimate team.

SLSA defines four maturity levels, from basic traceability to fully isolated, reproducible builds. For most Docker projects, SLSA Level 2 or 3 is a realistic goal: signed provenance from a hosted CI platform like GitHub Actions that attests the build process itself. GitHub Actions supports native provenance generation via `actions/attest-build-provenance`, without a team having to run its own attestation infrastructure.

7. Shipping your own images with provenance and signature

A team's own images represent exactly the same trust question for its customers or downstream teams as an external base image. Consistent supply chain security therefore means not only checking incoming base images, but also shipping your own images signed and with a provenance attestation. This is especially relevant when images are distributed to customers or across a larger organization with multiple teams.

A complete CI workflow for supply chain security typically includes: building the image with a pinned base image, generating an SBOM, signing with Cosign, attesting provenance, and pushing to the registry, all as one coherent, automated step without manual intermediate steps that would offer an attack surface for tampering.

#!/usr/bin/env bash
# Full release workflow: build, SBOM, sign, attest provenance, push
set -euo pipefail

IMAGE="myregistry.example.com/shop-api"
TAG="1.5.0"

docker build -t "${IMAGE}:${TAG}" .
docker push "${IMAGE}:${TAG}"

DIGEST=$(docker inspect "${IMAGE}:${TAG}" | jq -r '.[0].RepoDigests[0]' | cut -d@ -f2)

syft "${IMAGE}@${DIGEST}" -o cyclonedx-json > "sbom-${TAG}.json"
cosign sign --yes "${IMAGE}@${DIGEST}"
cosign attest --yes --predicate "sbom-${TAG}.json" --type cyclonedx "${IMAGE}@${DIGEST}"

echo "[OK] Released ${IMAGE}@${DIGEST} with signature and SBOM attestation"

8. Keeping base images current without losing control

Pinned digests solve the problem of uncontrolled changes but create a new one: without an active process, a once pinned base image stays on the same, eventually outdated state forever, with all its associated unfixed vulnerabilities. Supply chain security therefore needs a controlled update process that automatically proposes new digests but does not adopt them automatically and unchecked.

Renovate and Dependabot support exactly this pattern: a bot detects that a new, officially signed digest exists for a pinned base image, opens a pull request with the updated digest, and the regular CI pipeline, including image scanning and signature verification, runs like for any other change. This keeps supply chain security intact while updates still do not need to be tracked manually.

# renovate.json: automatically propose pinned digest updates for Dockerfiles
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "docker": {
    "pinDigests": true
  },
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["digest"],
      "automerge": false,
      "labels": ["supply-chain-security", "base-image-update"]
    }
  ]
}

9. Supply chain measures compared

The individual building blocks of supply chain security complement each other but cover different risks. The following table ranks them by effort and effect.

No single building block is sufficient for complete supply chain security. Digest pinning is the fastest first step with immediate effect, Cosign signing with enforced verification closes the biggest remaining gap, and SLSA provenance plus a curated registry are the consistent extension for organizations with higher compliance requirements.

10. Summary

Supply chain security for Docker base images starts with the insight that trust in a tag is not a security guarantee. Digest pinning makes base image references immutable, Cosign signing with enforced verification detects subsequent tampering, and SLSA provenance attestations confirm under which conditions an image was actually built. Together, these building blocks replace implicit trust with verifiable, cryptographically secured facts.

The practical entry point should be gradual: digest pinning first, because it takes effect immediately without additional infrastructure, then signing with enforced verification, and only after that full SLSA provenance for teams with corresponding compliance requirements. Each of these steps reduces the attack surface of your own supply chain security without requiring all steps to be implemented at once.

11. FAQ: Supply Chain Security for Docker Base Images