A Practical Software Supply Chain Security Checklist for Development Teams

Software supply chain security only works when it is built into the normal path from source code to production. A checklist that lives outside the delivery pipeline may satisfy an audit, but it will not stop a compromised base image, a poisoned dependency, or an over-permissioned CI token from moving with the release.

The five controls that matter most

Docker’s new guide organizes software supply chain security around five practical categories: trusted content, build security, pre-deployment verification, access and policy controls, and continuous monitoring. Docker software supply chain guide

That framing is useful because it follows the path an artifact actually takes. A team chooses a base image, pulls dependencies, builds in CI, produces evidence, stores the image, deploys it, and then monitors what runs. The controls should sit on that same path.

1. Start with trusted, pinned inputs

Docker recommends starting from trusted, minimal base images and pinning dependencies by digest rather than relying on mutable tags. Docker trusted-content guidance The reason is simple: a tag such as python:3.12 can point to different image bytes over time, while a digest identifies the specific image version the build should consume.

What to implement first

Use minimal base images, pin container images by SHA-256 digest, keep language dependencies locked to exact versions, and require the build to fail when committed hashes do not match downloaded packages. Those controls make upgrades deliberate instead of accidental.

2. Add provenance to the build

An SBOM tells you what is inside an artifact, but provenance tells you how the artifact was produced. Docker recommends generating signed provenance attestations that link artifacts back to source commit, build configuration, and builder identity. Docker build-provenance guidance

The SLSA project describes its framework as guidelines and tamper-resistant evidence for securing steps in the software production process, helping users trust that the analyzed source still corresponds to the binary they consume. SLSA overview SLSA provenance specifies metadata about how an artifact or set of artifacts was produced, which is the evidence deployment policy can later evaluate. SLSA provenance specification

Make CI a security boundary

The build system should be treated as privileged infrastructure. Docker’s guidance calls for fresh build environments, minimal secrets, CI plugins pinned to full commit SHAs, and branch protection before release branches are updated. Docker CI/CD hardening guidance

3. Produce SBOMs that people can use

Docker recommends generating SBOMs at every build and consuming them downstream in admission controllers, vulnerability scanners, and license checks. Docker SBOM guidance CycloneDX describes an SBOM object model that can represent components, services, dependencies, compositions, vulnerabilities, formulations, and other supply-chain metadata. CycloneDX specification overview

The practical test is whether the SBOM shortens response time. When a new vulnerability appears, a useful SBOM should help teams identify affected workloads quickly, understand whether the vulnerable component is actually present, and prioritize rebuilds or mitigations.

4. Put policy at the registry and pipeline

Docker’s guide recommends registry access controls, verified publishers or internal builds, and signature verification before images enter production. Docker registry-policy guidance

Least privilege matters more than slogans

The same section emphasizes scoping every credential, token, and API key to the minimum permissions required for its specific task. Docker also cites CISA’s recommendation for phishing-resistant multi-factor authentication on developer and CI/CD accounts. Docker least-privilege guidance

CISA’s software supply chain customer guide is part of a series developed with NSA and ODNI participation and includes guidance for procurement, testing, deployment, patching, and SBOMs. CISA software supply chain guide

5. Monitor runtime and rehearse response

Docker’s final category is monitoring and improvement. The guide argues that runtime monitoring catches unexpected behavior that build-time scanning misses, such as new outbound connections, file-system modifications, or unusual process execution in a running container. Docker runtime-monitoring guidance

NIST’s Secure Software Development Framework is formally published as SP 800-218 and gives organizations a structured way to reduce software-vulnerability risk across development practices. NIST SSDF SP 800-218 In practice, that means supply-chain controls should be reviewed as part of engineering operations, not only after an incident.

A starter implementation plan

Use incidents as design tests

Ask the program to answer concrete incident questions: Which running workloads use this vulnerable component? Which artifact built it? Which CI job had access to the signing key? Which registry policy allowed deployment? Which credentials need rotation? If the controls cannot answer those questions, the next improvement is clear.

The bottom line

Supply chain security is not a single product or a one-time hardening sprint. It is an engineering loop: control inputs, protect the build, generate evidence, enforce policy, watch runtime behavior, and rehearse recovery. The teams that get value from SBOMs, provenance, and scanning are the teams that wire those signals into everyday delivery decisions.

docker buildx build 
  --platform linux/amd64 
  --provenance=true 
  --sbom=true 
  --tag registry.example.com/team/app:${GIT_SHA} 
  --push .

cosign verify-attestation 
  --type slsaprovenance 
  --certificate-oidc-issuer https://token.actions.githubusercontent.com 
  registry.example.com/team/app@sha256:...