SBOM
Software bill of materials
A machine-readable inventory of the components in a software release and their relationships, usually in SPDX or CycloneDX. CISA’s 2026 minimum elements define baseline fields; completeness depends on how it was produced.
Covered in
Generate an SBOM for the software you actually release
Define the inventory boundary, compare build and artifact evidence, and connect the resulting SBOM to an immutable release.
Choose SBOM formats and identify components accurately
Separate schema versions, document references and package identities so inventory conversion and advisory matching preserve meaning.
Open source license compliance: SPDX expressions, obligations and SBOM checks
Know which licenses you ship, read SPDX license expressions correctly, meet the obligations of common licenses for the way you distribute, and enforce a license policy in CI from the SBOM.
Review SBOM changes between releases
Turn inventory differences into explainable release decisions without confusing generator changes with software changes.
Case study: Log4Shell (CVE-2021-44228)
How a JNDI lookup in Apache Log4j became internet-wide remote code execution, why transitive and shaded dependencies made it so hard to patch, which mitigations held, and what it teaches about dependency inventory and SBOMs.
Supplier software assurance: check SOC 2 reports, SBOMs and signed updates against your use
Connect supplier claims to product scope, supported versions, release integrity and vulnerability handling before making a procurement decision.
All 13 pages that cover SBOM in the library
Practice: SBOM completeness lab: Find the dependencies missing from a release SBOM · Local project: Build and verify a signed software release