No SBOM to Software Supply Chain Security Blueprint

What and Why

Without a software bill of materials (SBOM), an organization cannot answer the basic question "what is in our software?" When a critical vulnerability like Log4Shell lands, teams scramble for days to find affected artifacts, often by guesswork. Supply chain attacks (compromised dependencies, poisoned build pipelines) have become a primary threat. Supply chain security adds an SBOM for every build, cryptographic signing of artifacts, and provenance attestations that prove how and where something was built, aligning with the SLSA framework and NIST's Secure Software Development Framework (SSDF, SP 800-218).

The migration builds verifiable trust from source to deployed artifact, so consumers can confirm an artifact came from the expected pipeline and contains known components.

Phases

Assessment. Map the build and release pipeline for each artifact type (container images, language packages, binaries). Identify where dependencies enter, who can modify builds, what credentials the pipeline holds, and the current gaps: no SBOMs, unsigned artifacts, no provenance, shared mutable runners. Define the target SLSA level and the order in which artifact types will be addressed.

SBOM. Generate an SBOM on every build in a standard format (CycloneDX or SPDX) using tools like Syft or the build system's native support. Capture both direct and transitive dependencies with versions and hashes. Store SBOMs as attestations alongside artifacts in the registry, and feed them into vulnerability scanning (Grype, Trivy) so a newly disclosed CVE maps instantly to every affected release without rebuilding.

Signing. Sign artifacts and SBOMs with Sigstore Cosign using keyless signing, which binds short-lived certificates to the pipeline's workload identity via an OIDC token, so consumers can verify authenticity without anyone managing long-lived private keys. Record signatures in a transparency log.

Provenance. Emit build provenance attestations (SLSA provenance in the in-toto format) describing the source commit, the builder, the build parameters, and the materials consumed. Run builds on hardened, isolated, ephemeral runners so the provenance is trustworthy and a compromised build cannot silently forge it.

Enforcement. Add admission control (a policy controller in Kubernetes such as Sigstore policy-controller or Kyverno) that only allows artifacts with valid signatures and provenance to deploy. Gate releases on SBOM presence and vulnerability thresholds. Verify signatures and provenance at deploy time, and roll out enforcement gradually from warn to block.

Key Risks and Mitigations

• Dependency blind spots. Transitive dependencies hide most risk. Generate complete SBOMs including transitives, and continuously rescan stored SBOMs as new CVEs appear so old releases are reassessed automatically.
• Build tampering. A compromised builder undermines every downstream control. Use hardened, ephemeral, isolated runners, scope build credentials tightly, and rely on SLSA provenance to detect tampering.
• Policy friction. Hard enforcement can block releases and frustrate teams. Roll out in warn mode first, then enforce, provide a clear and audited exception process, and give developers fast feedback in the pipeline.

Recommended Tooling

Syft for SBOM generation, Grype or Trivy for scanning, Sigstore Cosign for keyless signing and the Rekor transparency log, in-toto/SLSA provenance generators, an OCI registry that stores attestations, and an admission/policy controller (Sigstore policy-controller or Kyverno) for deploy-time verification. Vault for any remaining build secrets.

Success Metrics

Track SBOM coverage across builds, percentage of signed artifacts with valid provenance, and vulnerability MTTR when a new CVE is disclosed.

Prerequisites

CI/CD that can run on hardened, ephemeral runners, an artifact registry that stores attestations, workload identity for keyless signing, and admission control in the deploy target.