Software supply chain security: SBOM and provenance guide

An SBOM is a machine-readable inventory of all components in a piece of software — direct and transitive dependencies, their versions, licences, and provenance. It is important because: when a vulnerability is disclosed (Log4Shell, XZ Utils), an SBOM enables immediate identification of all affected software; it supports licence compliance audits by inventorying all OSS licences in use; it is increasingly required by enterprise procurement (US federal agencies, EU Cyber Resilience Act) and by cyber insurance; and it provides the foundation for software provenance verification. Without an SBOM, organisations must manually audit thousands of dependencies in response to each major vulnerability disclosure.

SPDX (Software Package Data Exchange) is an ISO/IEC standard (5962:2021) with a long history in licence compliance and hosted by the Linux Foundation. CycloneDX is an OWASP project with stronger security-specific fields — vulnerability disclosure, exploit attestations, and attack surface modelling. SPDX is the official ISO standard and preferred for licence compliance workflows. CycloneDX is the preferred format for security-focused SBOMs and is what US government SBOM requirements (CISA, NIST) reference most frequently. Most tools generate both formats; choose based on your primary use case, or generate both and serve the appropriate format to different consumers.

SLSA (Supply chain Levels for Software Artefacts) is a security framework that defines maturity levels for build provenance — cryptographically signed attestations proving an artefact was built from a specific source, at a specific commit, using a specific build process, in a trusted environment. SLSA addresses the build integrity problem: without provenance, you cannot verify that a binary matches the source code it claims to be built from. SLSA Level 2 (hosted build service with provenance) prevents most practical supply chain attacks. SLSA Level 3 (hardened build environment) provides strong protection against sophisticated insider threats. SLSA provenance is generated by GitHub Actions, Google Cloud Build, and other SLSA-compliant build services.

Sigstore is an open-source project (Google, Red Hat, Purdue University) that provides a keyless code signing infrastructure using ephemeral keys tied to identity rather than long-lived private keys. Instead of managing private keys for signing artefacts, Sigstore uses OpenID Connect (OIDC) tokens from identity providers (GitHub Actions, Google, Microsoft) as the signing identity. The ephemeral key is signed by Sigstore's Fulcio certificate authority, and the signing event is recorded in Rekor (an immutable transparency log). Verifiers can check signatures without trusting the signer's key management — only that they authenticated with a trusted identity provider at signing time.

SBOM generation should be a post-build step in CI/CD: after building the application artefact or container image, run Syft, cdxgen, or Trivy against the built artefact to generate the SBOM. Attach the SBOM to the artefact (embedded in container image OCI metadata for containers; stored alongside the binary for other artefacts). Push the SBOM to a registry (Dependency Track, JFrog Xray, or an OCI-compatible registry). Set a pipeline gate that fails the build if the SBOM contains components with CVSS score above a defined threshold. This ensures every deployed artefact has a current, accurate SBOM and no known critical vulnerabilities at deployment time.

SBOM requirements are becoming mandatory in several contexts. US Executive Order 14028 (2021) requires software sold to US federal agencies to provide SBOMs. The EU Cyber Resilience Act (CRA), finalised in 2024 and entering application from 2026–2027, requires CE-marked digital products to include SBOMs and maintain a software component inventory. US FDA guidance requires SBOMs for medical device software. CISA (Cybersecurity and Infrastructure Security Agency) publishes SBOM minimum requirements referenced by government procurement. Enterprise software buyers (large financial institutions, critical infrastructure operators) are increasingly requiring SBOMs from software vendors as part of procurement security assessments.

Dependency Track is an OWASP open-source platform that ingests SBOMs from your software artefacts and continuously monitors them against vulnerability databases (NVD, OSV, GitHub Advisory Database, Sonatype OSS Index) for known CVEs. When a new vulnerability is disclosed, Dependency Track automatically identifies which of your artefacts contain the affected component and generates alerts. It provides a dashboard showing portfolio-level vulnerability exposure, licence compliance status, and SBOM coverage. Dependency Track integrates with CI/CD pipelines to fail builds that introduce vulnerable components and with ticketing systems (Jira, ServiceNow) to create remediation tickets automatically.

A traditional application vulnerability is a flaw in code you wrote — a SQL injection, buffer overflow, or authentication bypass in your own application. A supply chain attack compromises software you depend on — an open-source library, a build tool, a package registry, or a deployment pipeline. Supply chain attacks are particularly dangerous because they affect all consumers of the compromised component simultaneously (Log4Shell affected millions of Java applications at once), the malicious code may be present for months before discovery (XZ Utils backdoor was in development for two years), and traditional application security testing doesn't scan for supply chain compromise. SBOM and provenance controls address supply chain risk; SAST/DAST and code review address application vulnerabilities.