Software Bill of Materials (SBOM) and supply chain security form the backbone of modern software transparency — a structured answer to the question "exactly what is in my software, and can I trust how it was built?" Driven by high-profile incidents like SolarWinds and Log4Shell, regulators in the US (Executive Order 14028) and EU (Cyber Resilience Act) now mandate SBOMs for software sold to governments and digital product markets. The core mental model: an SBOM is a nested ingredient list, but it only becomes security-relevant when paired with provenance attestations (proving how software was built), vulnerability lookups (proving what's known-bad in those ingredients), and policy enforcement (blocking deployments that fail either check). Understanding the interplay between formats, generation tools, signing infrastructure, and consumption workflows is what separates a compliance checkbox from an operational security capability.
What This Cheat Sheet Covers
This topic spans 18 focused tables and 97 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: SBOM Formats
SBOM formats define the schema and encoding used to represent a software inventory. Choosing the right format affects interoperability with vulnerability scanners, license analyzers, and regulatory submission tools.
| Format | Example | Description |
|---|---|---|
{"bomFormat":"CycloneDX","specVersion":"1.6","components":[...]} | • Lightweight OWASP-originated SBOM standard designed for application security and supply chain analysis • supports JSON, XML, and Protocol Buffers • widely adopted for vulnerability scanning workflows | |
{"spdxVersion":"SPDX-2.3","dataLicense":"CC0-1.0","packages":[...]} | • ISO/IEC 5962:2021 international open standard hosted by the Linux Foundation • excels at license compliance tracking • supports JSON, YAML, RDF, and tag-value formats |