Pin base image references to SHA256 digests to prevent tag-mutability supply chain attacks

[MateuszSlojkowski]

Pin base image references to SHA256 digests to prevent tag-mutability supply chain attacks

DescriptionThe Dockerfiles in this repository currently reference the Alpine base image using a mutable tag:

FROM alpine:3.23

(e.g. 22/alpine3.23/Dockerfile#L1)

This applies to all Alpine-based variants across all supported Node.js major versions, as well as to the Debian-based variants that reference debian:bookworm-slim, debian:bullseye-slim, etc.

Mutable tags are inherently vulnerable to tag-overwrite attacks: a compromised registry account or a man-in-the-middle could push a different image under the same tag, and subsequent builds of the official Node.js image would silently pull the tampered base layer.

Proposed change

Pin every FROM directive to the image digest in addition to the human-readable tag:

FROM alpine:3.23@sha256:25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659

This retains readability (the tag is still visible) while ensuring that Docker resolves the image strictly by its content-addressable hash. Any change to the upstream image — whether legitimate or malicious — will require an explicit, auditable digest update in this repository.

Motivation

The recent CanisterWorm / TeamPCP supply chain campaign (March 2026) demonstrated how a single compromised upstream component can cascade through CI/CD pipelines and developer environments at scale. While that specific attack targeted npm packages via the Trivy scanner compromise, the underlying lesson applies broadly: every mutable reference in a build pipeline is a potential injection point.

Pinning base images by digest is a well-established best practice recommended by:

• OWASP Node.js Docker Cheat Sheet — recommends digest pinning for deterministic, tamper-resistant builds
• Docker official documentation — recommends using @sha256: references
• Snyk best practices for containerizing Node.js — lists digest pinning as a key hardening step
• SLSA Supply Chain Levels — hermetic builds require pinned, content-addressable dependencies

Given the scale of the official Node.js Docker image (billions of pulls), hardening the build-time base image reference has an outsized positive impact on the broader ecosystem.

Maintenance considerations

Digest pinning introduces a maintenance requirement: digests must be updated when upstream Alpine/Debian images receive security patches. This is a well-solved problem:

• Renovate and Dependabot both support automated PRs for Docker digest updates.
• The update.sh / image generation scripts in this repository could be extended to resolve and embed the current digest at generation time.
• A CI check (e.g. docker scout, hadolint) can flag unpinned FROM directives.

Scope

This change would apply to:

• All alpine3.xx variants (FROM alpine:3.xx)
• All bookworm / bullseye / trixie variants (FROM debian:*)
• All slim variants

References

• CanisterWorm / TeamPCP campaign (The Hacker News, March 2026)
• CanisterWorm analysis (KrebsOnSecurity, March 2026)
• CSA Research Note: CanisterWorm Blockchain C2
• Aqua Security Trivy advisory — GHSA-69fq-xp46-6x23

[nschonni]

This is a base image, and is rebuilt by the infrascructure for the official images, so doing this would not make sense. The images are automatically rebuilt and republished upstream when the base images are patched.

Pinning can make sense for your own apps though