Skip to main content

SBOM & Supply-Chain Security Review Checklist

A supply-chain security review that starts with per-build SBOMs for visibility, then adds continuous dependency scanning, trusted sourcing, reproducible isolated builds, artifact signing, and SLSA provenance attestations. The goal is to know what is in your software and prove how it was built.

Estimated Time
1 day
Type
security audit
Category
Security
Steps
12

When to Use This Checklist

Use this checklist when securing a software supply chain, preparing for a compliance requirement that mandates an SBOM, or responding to a supply-chain incident. Modern applications are mostly third-party code, and attackers increasingly target the build and dependency chain rather than the application itself. This review verifies you know what is in your software and can prove how it was built.

How to Use This Checklist

Start with visibility. An SBOM, a machine-readable inventory of every component in a build, is the foundation; generate one for every build and store it with the artifact. With visibility in place, layer on integrity: scan dependencies continuously, source base images from trusted registries, and make builds reproducible in isolated, ephemeral environments so the build cannot be tampered with.

Then prove integrity to consumers. Sign artifacts and verify signatures before deployment, and generate provenance attestations that describe exactly how each artifact was produced. Assessing the pipeline against SLSA levels gives a concrete maturity target.

What Good Looks Like

Every build emits an SBOM and is scanned against known vulnerabilities, so a newly disclosed CVE can be matched to affected artifacts in minutes. Dependencies are pinned and sourced from trusted registries, and builds run in clean, isolated environments that produce identical outputs. Artifacts are signed, and deployments refuse unsigned or unverified artifacts. Provenance attestations make the build process auditable, and publishing rights to registries are tightly controlled. The team has a rehearsed process to triage and remediate emerging CVEs.

Common Pitfalls

The biggest gap is having no SBOM, which means that when a critical CVE drops, the team cannot answer whether they are affected. Pulling base images from untrusted or unpinned sources invites tampered dependencies. Builds that are not reproducible or run with broad access let malicious dependency code exfiltrate build secrets. Finally, deploying unsigned artifacts means there is no guarantee that what runs in production is what the pipeline actually built.

Related Resources

Use CycloneDX for SBOMs, SLSA as a maturity framework, and Sigstore keyless signing with in-toto attestations to prove provenance. Combine with NIST SSDF and reproducible builds for a defensible secure development lifecycle.