SBOM and Build Provenance

SBOM and Build Provenance

Know exactly what is in your software (SBOM) and prove how it was built (provenance) -- because you cannot secure what you cannot inventory

When to Use

• Responding to a new CVE and need to know which deployments include the affected library
• Meeting regulatory requirements for software transparency (US Executive Order 14028, EU Cyber Resilience Act)
• Implementing SLSA (Supply-chain Levels for Software Artifacts) to harden the build pipeline
• Publishing software to customers who require SBOMs as part of procurement
• Auditing the software supply chain for compliance or security review
• Investigating whether a compromised upstream dependency is present in your deployed artifacts

Threat Context

The 2021 US Executive Order 14028 on Improving Cybersecurity requires SBOMs for software sold to the federal government. The EU Cyber Resilience Act extends similar requirements to all software sold in the EU market. Beyond compliance, SBOMs enable rapid vulnerability response: when Log4Shell (CVE-2021-44228) dropped in December 2021, organizations with SBOMs identified all affected applications in minutes. Organizations without SBOMs spent days to weeks manually searching codebases, build artifacts, and container images -- many discovered affected deployments only after active exploitation was detected.

Build provenance addresses the SolarWinds-class attack: the SUNBURST backdoor was injected into a legitimate build artifact by compromising the build pipeline. The signed, "trusted" artifact contained malicious code. Code signing alone could not detect this because the signing happened after the injection. SLSA provenance proves that an artifact was built from a specific source commit, on a specific build system, using a specific build process. Without provenance, a compromised CI system can produce arbitrary artifacts and no consumer can detect the tampering.

The combination of SBOM (what is in the artifact) and provenance (how the artifact was built) forms the foundation of software supply chain security. Neither alone is sufficient.

Instructions

1. Generate SBOMs as part of the build process. Use SPDX or CycloneDX format -- both are ISO standards with broad tooling support. Tools for SBOM generation: syft (Anchore, generates SBOMs for containers and filesystems), cdxgen (CycloneDX generator supporting 20+ ecosystems), spdx-sbom-generator (SPDX native), trivy sbom (Aqua Security, combined vulnerability scanning and SBOM generation). Generate the SBOM in CI at the same build step that produces the artifact. Store the SBOM alongside the artifact -- they are a pair.

2. Include both direct and transitive dependencies. An SBOM that lists only direct dependencies misses approximately 90% of the dependency tree. A vulnerability in a transitive dependency is just as exploitable as one in a direct dependency. Use tools that resolve the full dependency graph. For each component include: package name, exact version, license, supplier, and package URL (purl) for unambiguous identification across ecosystems.

3. Implement SLSA build provenance. SLSA defines four levels of supply chain security. Level 1: the build process is documented. Level 2: the build service generates provenance attestations automatically. Level 3: the build service is hardened and provenance is unforgeable (the build service, not the developer, generates the attestation). Level 4: all dependencies are recursively verified with hermetic, reproducible builds. Start with SLSA L1 (document the build process), move to L2 (use GitHub Actions with slsa-github-generator or Sigstore to generate signed provenance), then plan for L3 (hardened build service with non-falsifiable provenance).

4. Sign provenance attestations. Use in-toto attestations (the CNCF standard for build provenance) signed with Sigstore (keyless signing using OIDC identity). The attestation binds the artifact (by cryptographic digest) to the source commit, builder identity, and build parameters. Consumers verify the attestation to confirm the artifact was built from the expected source by the expected builder. Without signing, provenance attestations can be forged by anyone with write access to the artifact store.

5. Store and distribute SBOMs alongside artifacts. Attach SBOMs to container images as OCI artifacts using oras, cosign attach sbom, or docker buildx with attestation support. Publish SBOMs to a central management platform (Dependency-Track, GUAC) for organization-wide visibility. Make SBOMs available to customers and auditors upon request -- this is a regulatory requirement in many jurisdictions, not a courtesy.

6. Use SBOMs for continuous vulnerability management. Ingest SBOMs into a vulnerability management tool (Dependency-Track, Grype, Trivy) that correlates SBOM components against vulnerability databases (NVD, OSV, GitHub Advisory Database). When a new CVE is published, immediately identify all affected artifacts across the organization and prioritize patching based on exposure and severity. This turns vulnerability response from a manual search into an automated query.

7. Verify provenance before deployment. Integrate provenance verification into the deployment pipeline. In Kubernetes, use Kyverno or Sigstore policy-controller to verify SLSA provenance at admission time. Reject artifacts that lack provenance or whose provenance does not match the expected builder identity and source repository. Generating provenance without verifying it provides no security benefit.

Details

• SPDX vs CycloneDX comparison: SPDX (Linux Foundation, ISO/IEC 5962:2021) is the more mature format with strong license compliance features. It supports documents, packages, files, and relationships. CycloneDX (OWASP) is newer and more security-focused, with native support for vulnerability correlation, services, and formulation (build provenance). Both are valid choices. For security-focused SBOM work, CycloneDX has better tooling integration. For license compliance, SPDX is more established. Many organizations generate both formats from the same source data.

• SLSA levels in practice: Most organizations should target SLSA L2 immediately -- it requires only that the build service generates signed provenance, which GitHub Actions and Google Cloud Build support natively. SLSA L3 requires that the build service is hardened such that insiders and project maintainers cannot influence the provenance generation -- this typically requires using an isolated build service like Google Cloud Build or the SLSA GitHub generator (which runs in a reusable workflow the project cannot modify). SLSA L4 (hermetic, reproducible builds with recursive dependency verification) is aspirational for most organizations and primarily relevant for critical infrastructure software.

• in-toto framework: Defines a "supply chain layout" that specifies which steps are allowed, who performs them, and what artifacts each step produces. Each step generates a "link" attestation signed by the step's functionary. The final verification checks that all required steps were performed by authorized actors and that artifact digests chain correctly from source to final artifact. This provides end-to-end verification of the entire build process, not just the final signing step.

• GUAC (Graph for Understanding Artifact Composition): An open-source project (Google-led) that ingests SBOMs, SLSA attestations, and vulnerability data into a graph database. Enables queries like "which of my deployed artifacts are affected by CVE-2021-44228?" and "what is the full dependency chain from this artifact to the vulnerable library?" GUAC provides the queryable intelligence layer on top of raw SBOM and provenance data.

• Package URL (purl) specification: A standardized format for identifying software packages across ecosystems: pkg:npm/%40angular/[email protected], pkg:pypi/[email protected], pkg:maven/org.apache.logging.log4j/[email protected]. Using purls in SBOMs enables unambiguous cross-ecosystem vulnerability correlation. Without purls, matching "lodash 4.17.21" in an SBOM to a CVE advisory requires ecosystem-specific logic.

Anti-Patterns

1. Generating SBOMs only on demand. An SBOM generated after a CVE is discovered requires re-running the build analysis on the deployed version, which may not be reproducible weeks or months later. Dependencies may have changed, lock files may have been updated, and the exact build environment may no longer exist. Generate SBOMs in CI for every release and store them as permanent artifacts alongside the build output.

2. SBOMs without version specificity. An SBOM that lists "lodash" without a version, or "log4j" without distinguishing between log4j-core and log4j-api, is useless for vulnerability correlation. Every component must include an exact version and ideally a package URL (purl) for unambiguous identification across vulnerability databases.

3. Provenance without verification. Generating SLSA provenance but never verifying it before deployment is security theater. The provenance exists, the compliance checkbox is checked, but the deployment pipeline accepts any artifact regardless. Integrate provenance verification into admission control so that unverified artifacts are rejected.

4. Treating SBOM as a one-time compliance artifact. Generating an SBOM once per year for an audit captures a snapshot that is stale within days. Vulnerability databases update daily with newly disclosed CVEs. SBOMs should be generated for every build and continuously correlated against current vulnerability data.

5. No SBOM for container base images. The base image (Debian, Alpine, Ubuntu) often contains more OS packages than the application layer. A vulnerability in a base image library (OpenSSL, glibc, zlib) affects every application built on that image. Include base image components in the SBOM, or layer the application SBOM on top of the base image SBOM. Tools like Syft and Trivy scan the full container filesystem, capturing both layers.

6. Confusing SBOM with dependency lock files. A lock file (package-lock.json, Pipfile.lock) records direct and transitive dependency versions for reproducible builds. An SBOM is a broader document that includes license information, supplier data, component relationships, and can cover non-package components (OS libraries, configuration files, embedded firmware). Lock files are a build tool input; SBOMs are a security and compliance output.