Why the Software Supply Chain Matters

Summary

The software supply chain is every input, tool, and step that turns your source code into a running container in a cluster.
Insight: A container image is not a mystery box. It is a versioned, content-addressed, signable artifact, and that lets you attach trust to it.
Key Concepts: A digest is the SHA-256 hash of an image's content. Provenance records how and where an image was built. An attestation is signed metadata (SBOM, provenance) bound to a digest.
When to Use: Always. Every team shipping containers already has a supply chain; the only question is whether it is governed or accidental.
Limitations/Trade-offs: Full verification (signing, SBOMs, admission gating) adds pipeline steps and key management overhead you must operate.
Related Topics: Image signing, SBOM generation, tag immutability, and registry authentication.

Foundations

Your users run the image, not your source code.

Between a git commit and a pod, dozens of untrusted inputs enter: base images, OS packages, language dependencies, build tools, and CI runners.

An attacker who compromises any one of those inputs can ship malicious code that never appeared in your repository.

This is why supply chain security shifted from "review the code" to "prove the artifact."

The mental model that makes this tractable is treating an image as an immutable artifact identified by its digest.

A tag like app:1.4.0 is a mutable pointer, but app@sha256:abc123... names exact bytes that can never change.

Once you can name exact bytes, you can sign them, scan them, and record where they came from.

That chain of verifiable facts - from source to build to registry to cluster - is the trust chain.

Mechanics & Interactions

An OCI image is a manifest that lists a config blob plus content-addressed layer blobs.

The manifest itself has a digest, and that digest is what a registry, containerd, and a signature all agree on.

When you docker push, BuildKit uploads the layers and manifest to a registry such as Harbor, ECR, or GHCR.

When a pod is scheduled, the kubelet asks containerd to pull that image by tag, and containerd resolves the tag to a digest before pulling.

If you pin the digest in your manifest, the resolution step is skipped and you get exactly the bytes you tested.

Signing sits on top of this.

Tools like cosign generate a signature over the image digest and store it in the same registry as an associated artifact, optionally recording it in the Sigstore transparency log.

At deploy time, an admission controller (Kyverno, or a policy engine using Sigstore policy) intercepts the pod, looks up the signature for the image digest, and verifies it against a trusted key or identity before allowing the pod to run.

SBOMs and provenance flow the same way.

BuildKit can emit an SBOM and SLSA provenance as attestations attached to the image, so a scanner or auditor can ask "what is inside this exact digest and how was it built" without rebuilding anything.

The pieces interact through one shared anchor: the digest.

Advanced Considerations & Applications

The most common real-world attacks map cleanly onto stages of this chain.

Dependency confusion and typosquatting poison the inputs, which is why you pin and mirror dependencies internally.

A compromised CI runner or leaked registry credential poisons the build and publish steps, which is why push identities should be short-lived OIDC tokens, not static passwords.

A mutable tag repointed to a bad image poisons the deploy step, which is why production should pull by digest and enforce immutable tags at the registry.

At scale, you cannot manually verify anything, so verification must be policy that runs automatically.

The SLSA framework gives a useful maturity ladder: from "builds are scripted" up to "builds are hermetic and produce non-forgeable provenance."

Most teams land in the middle: reproducible-ish builds, signed images, generated SBOMs, and admission policies that reject unsigned or unknown images.

The payoff is concrete during an incident.

When a critical CVE lands in a common library, an SBOM index lets you answer "which of our 400 images ship the vulnerable version" in minutes instead of days.

Common Misconceptions

"We scan images, so our supply chain is secure."

Scanning finds known vulnerabilities in what you already built; it does nothing to prove the image was not tampered with after the build.

"Signing encrypts the image."

Signing does not change or hide the image bytes at all; it attaches a verifiable claim that a specific identity vouched for a specific digest.

"Pulling from a private registry means the image is trusted."

A private registry controls who can push and pull, but anyone with push access, or a poisoned build, can still place a bad image there.

"Using :latest from an official base image is fine."

:latest is a moving pointer, so the same manifest can silently resolve to different bytes over time, breaking reproducibility and auditability.

"Provenance and SBOMs are only for regulated industries."

They are increasingly required by customers and frameworks, but their day-one value is operational: fast CVE triage and clear blast-radius answers.

FAQs

Is a digest the same as a tag?

No. A tag is a human-friendly, mutable label; a digest is an immutable SHA-256 hash of the image content that never points to different bytes.

Where do signatures and SBOMs actually live?

They are stored as OCI artifacts in the same registry alongside the image, associated with the image's digest.

Does Kubernetes verify signatures on its own?

No. The kubelet and containerd pull images but do not check signatures; you add an admission controller such as Kyverno or a Sigstore-aware policy to enforce that.

What is the single highest-value first step?

Deploy by digest and forbid mutable tag overwrites in production, so what you tested is exactly what runs.

How does this relate to the Docker versus containerd split?

You use Docker and BuildKit to build and push; containerd via the CRI pulls and runs images in the cluster, and both agree on the digest.

Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).

Why the Software Supply Chain Matters

Summary

The software supply chain is every input, tool, and step that turns your source code into a running container in a cluster.
Insight: A container image is not a mystery box. It is a versioned, content-addressed, signable artifact, and that lets you attach trust to it.
Key Concepts: A digest is the SHA-256 hash of an image's content. Provenance records how and where an image was built. An attestation is signed metadata (SBOM, provenance) bound to a digest.
When to Use: Always. Every team shipping containers already has a supply chain; the only question is whether it is governed or accidental.
Limitations/Trade-offs: Full verification (signing, SBOMs, admission gating) adds pipeline steps and key management overhead you must operate.
Related Topics: Image signing, SBOM generation, tag immutability, and registry authentication.

Foundations

Your users run the image, not your source code.

Between a git commit and a pod, dozens of untrusted inputs enter: base images, OS packages, language dependencies, build tools, and CI runners.

An attacker who compromises any one of those inputs can ship malicious code that never appeared in your repository.

This is why supply chain security shifted from "review the code" to "prove the artifact."

The mental model that makes this tractable is treating an image as an immutable artifact identified by its digest.

A tag like app:1.4.0 is a mutable pointer, but app@sha256:abc123... names exact bytes that can never change.

Once you can name exact bytes, you can sign them, scan them, and record where they came from.

That chain of verifiable facts - from source to build to registry to cluster - is the trust chain.

Mechanics & Interactions

An OCI image is a manifest that lists a config blob plus content-addressed layer blobs.

The manifest itself has a digest, and that digest is what a registry, containerd, and a signature all agree on.

When you docker push, BuildKit uploads the layers and manifest to a registry such as Harbor, ECR, or GHCR.

When a pod is scheduled, the kubelet asks containerd to pull that image by tag, and containerd resolves the tag to a digest before pulling.

If you pin the digest in your manifest, the resolution step is skipped and you get exactly the bytes you tested.

Signing sits on top of this.

Tools like cosign generate a signature over the image digest and store it in the same registry as an associated artifact, optionally recording it in the Sigstore transparency log.

SBOMs and provenance flow the same way.

The pieces interact through one shared anchor: the digest.

Advanced Considerations & Applications

The most common real-world attacks map cleanly onto stages of this chain.

Dependency confusion and typosquatting poison the inputs, which is why you pin and mirror dependencies internally.

A compromised CI runner or leaked registry credential poisons the build and publish steps, which is why push identities should be short-lived OIDC tokens, not static passwords.

A mutable tag repointed to a bad image poisons the deploy step, which is why production should pull by digest and enforce immutable tags at the registry.

At scale, you cannot manually verify anything, so verification must be policy that runs automatically.

The SLSA framework gives a useful maturity ladder: from "builds are scripted" up to "builds are hermetic and produce non-forgeable provenance."

Most teams land in the middle: reproducible-ish builds, signed images, generated SBOMs, and admission policies that reject unsigned or unknown images.

The payoff is concrete during an incident.

When a critical CVE lands in a common library, an SBOM index lets you answer "which of our 400 images ship the vulnerable version" in minutes instead of days.

Common Misconceptions

"We scan images, so our supply chain is secure."

Scanning finds known vulnerabilities in what you already built; it does nothing to prove the image was not tampered with after the build.

"Signing encrypts the image."

Signing does not change or hide the image bytes at all; it attaches a verifiable claim that a specific identity vouched for a specific digest.

"Pulling from a private registry means the image is trusted."

A private registry controls who can push and pull, but anyone with push access, or a poisoned build, can still place a bad image there.

"Using :latest from an official base image is fine."

:latest is a moving pointer, so the same manifest can silently resolve to different bytes over time, breaking reproducibility and auditability.

"Provenance and SBOMs are only for regulated industries."

They are increasingly required by customers and frameworks, but their day-one value is operational: fast CVE triage and clear blast-radius answers.

FAQs

Is a digest the same as a tag?

No. A tag is a human-friendly, mutable label; a digest is an immutable SHA-256 hash of the image content that never points to different bytes.

Where do signatures and SBOMs actually live?

They are stored as OCI artifacts in the same registry alongside the image, associated with the image's digest.

Does Kubernetes verify signatures on its own?

No. The kubelet and containerd pull images but do not check signatures; you add an admission controller such as Kyverno or a Sigstore-aware policy to enforce that.

What is the single highest-value first step?

Deploy by digest and forbid mutable tag overwrites in production, so what you tested is exactly what runs.

How does this relate to the Docker versus containerd split?

You use Docker and BuildKit to build and push; containerd via the CRI pulls and runs images in the cluster, and both agree on the digest.

Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).

Why the Software Supply Chain Matters

Buscar en la documentación

Why the Software Supply Chain Matters