Software supply chain for containers: registries, signing, SBOMs and provenance

Why the supply chain is a target

A typical container image contains your code, hundreds of open-source packages and a base image built by someone else. It passes through source control, a CI system, a registry and a deployment tool. An attacker who compromises any of these can reach every customer at once. Well-known incidents such as the SolarWinds build compromise, malicious packages published to public registries and the backdoor found in the xz utilities in 2024 showed how effective this route can be.

Common supply chain threats include typosquatting (a package named almost like a popular one), dependency confusion (a public package with the same name as an internal one), compromised maintainer accounts, tampered build systems and images swapped in a registry.

Registries and trusted sources

• Pull base images and dependencies through a private registry or proxy you control, rather than straight from the internet in production.
• Restrict who can push, require authentication for pulls, and enable vulnerability scanning on the registry.
• Use immutable tags where the registry supports them, so a released tag cannot be overwritten.
• Deploy by digest so the content cannot change underneath you.

Signing, SBOMs and provenance

Image signing lets consumers check who published an image and that it has not changed. The open-source Sigstore project, with its cosign tool, is widely used. It supports keyless signing, where a short-lived certificate tied to the CI job's identity is used and the signature is recorded in a public transparency log.

cosign sign registry.example.com/shop/api@sha256:<digest>
cosign verify registry.example.com/shop/api@sha256:<digest> \
  --certificate-identity-regexp 'https://github.com/example-org/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

A software bill of materials (SBOM) is an inventory of every component and version in the image, in a standard format such as SPDX or CycloneDX. When a new vulnerability is announced you can search SBOMs to find which images are affected in minutes instead of days. Tools like Syft or Trivy generate them during the build.

Provenance is a signed statement of how an artefact was built: which source commit, which build system, which steps. The SLSA framework (Supply-chain Levels for Software Artifacts) defines increasing levels of build integrity, from simply having provenance up to hardened, isolated build platforms. A VEX (Vulnerability Exploitability eXchange) document can state that a listed CVE does not actually affect a product, which helps reduce noise.

Enforcing it at deploy time

1. Build in CI, generate an SBOM and provenance, and sign the image and attestations.
2. Push to a private registry with scanning and immutable tags.
3. In Kubernetes, use an admission controller (for example Kyverno, OPA Gatekeeper or Sigstore policy-controller) to verify signatures before pods start.
4. Allow images only from approved registries.
5. Store SBOMs centrally and query them when new CVEs appear.

Tip: signing only helps if something checks the signature. Start in audit mode to see what would be blocked, then switch to enforce.