A Software Bill of Materials (SBOM) is a structured, machine-readable list of the components that make up a software artifact: open-source libraries, proprietary packages, operating system packages, programming language dependencies, and the transitive dependencies of all of the above. It is the software analogue of the ingredient list on packaged food — the thing that tells a consumer (or an automated system) precisely what is inside. The term and concept predate current security mandates but became a regulatory requirement in the US through Executive Order 14028 (May 2021), which directed NIST and NTIA to define minimum SBOM elements for software sold to the federal government. The NTIA’s resulting guidance specifies seven minimum data fields per component: supplier name, component name, version, component identifier (CPE or PURL), dependency relationships, SBOM author, and timestamp. The practical use cases SBOMs enable are vulnerability management (correlating component versions against CVE databases to identify affected software), licence compliance (detecting GPL or other licence obligations across the dependency graph), and incident response (determining within minutes which systems in a fleet contain a newly-disclosed vulnerable component, as organisations that had SBOMs could do during the Log4Shell response and those without could not).
Two formats dominate production use. SPDX (Software Package Data Exchange, ISO/IEC 5962:2021) originated at the Linux Foundation, focuses on licence expression and is the format most commonly produced by build tooling such as Syft, Trivy, and the Go and Java build ecosystems. CycloneDX (OWASP) takes a broader “bill of materials” framing, supports not just software components but services, hardware, and firmware, and has stronger native support for vulnerability data including embedded VEX statements and CycloneDX’s own Vulnerability Disclosure Report (VDR) format. Both formats support JSON, XML, and — in SPDX’s case — tag-value text. A third format, SWID tags (ISO/IEC 19770-2), is used primarily in firmware and enterprise software asset management contexts but sees limited use in cloud-native supply chains. The two primary formats are not automatically interoperable; tools such as CycloneDX’s cdxgen and anchore’s syft can produce either, and CISA’s SBOM sharing guidance recommends accepting both at ingestion boundaries. Component identity across formats is best addressed through PURLs (Package URLs, pkg:type/namespace/name@version), a format-neutral scheme for uniquely identifying a package across ecosystems that both SPDX and CycloneDX support.
SBOMs are most valuable when they travel with the artifact they describe and when they are verifiable. In the OCI ecosystem, SBOMs are attached to container images as OCI referrers — pushed to the same registry as the image they document, linked via the subject field, and discoverable via the referrers API with artifactType: application/spdx+json or application/vnd.cyclonedx+json. Tools such as ORAS and cosign handle the attachment and retrieval. Signing an SBOM (via cosign or Notation) with a key rooted in a PKI or Sigstore’s certificate transparency log binds the SBOM to a verified identity and makes tampering detectable. For bootc and image-based Linux systems, an OS-level SBOM attached to the OCI OS image as a referrer allows operators and automated compliance systems to know the exact package versions in a deployed OS image, query them against vulnerability databases, and verify the SBOM has not been substituted — forming the foundation of a software supply chain that is both transparent and attested. SBOM generation is increasingly automated: Tekton and GitHub Actions pipelines produce SBOMs as a build step, rpm --query --provides and dpkg-query extract OS package lists, and language-ecosystem tools like cyclonedx-gomod and syft walk dependency graphs at build time.