SBOM and Supply Chain Security Cheat Sheet

Updated 2026-08-01

Next Topic: Service Level Objectives Cheat Sheet

🧠Study flashcards on this topic72 cards · spaced repetition→

Software Bill of Materials (SBOM) and supply chain security form the backbone of modern software transparency: a structured answer to the question of exactly what is in a piece of software and how it got there. High-profile incidents like SolarWinds, Log4Shell, and the 2025-2026 self-propagating npm worm campaigns turned SBOM adoption from a nice-to-have into a regulatory requirement, with the 2026 CISA/NSA minimum elements replacing the original 2021 NTIA baseline and the EU's Cyber Resilience Act starting to bite from September 2026. The core mental model: an SBOM is a nested ingredient list, but it only becomes security-relevant once paired with vulnerability lookups (what's known-bad in those ingredients) and VEX statements (whether that known-bad code is actually reachable). Artifact signing and build-provenance attestation, such as Sigstore, in-toto, and SLSA, sit one layer above the SBOM itself; this article stays focused on the inventory: its formats, how it's generated and validated, and how the wider package-registry ecosystem around it gets attacked and defended.

What This Cheat Sheet Covers

This topic spans 12 focused tables and 77 indexed concepts, 72 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: SBOM FormatsTable 2: SBOM Minimum Elements (2026 CISA Baseline)Table 3: SBOM Generation and Validation ToolsTable 4: SBOM Generation WorkflowsTable 5: SBOM Consumption, Storage, and Vulnerability LookupTable 6: VEX and Vulnerability Status FormatsTable 7: SBOM Quality PitfallsTable 8: Regulatory DriversTable 9: Regulated Industry Operational PatternsTable 10: OpenSSF Supply Chain Tools and FrameworksTable 11: Package Registry Attacks and Publishing IntegrityTable 12: Lockfiles and Reproducible Builds

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

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
CycloneDX	`{"bomFormat":"CycloneDX","specVersion":"1.7","components":[...]}`	• OWASP flagship, Ecma-standardized SBOM format (ECMA-424, 2nd Edition, December 2025) built for application security and supply chain analysis • version 1.7 (October 2025) is the final release in the 1.x line, staying backward compatible with 1.4 through 1.6 • supports JSON, XML, and Protocol Buffers
SPDX	`{"spdxVersion":"SPDX-3.0.1","dataLicense":"CC0-1.0","creationInfo":{...}}`	• Linux Foundation project; the 2.2.1 line is codified as ISO/IEC 5962:2021, while the current 3.0.1 spec (April 2024, with a 3.1 release candidate) uses a new element-based model with optional profiles • excels at license compliance tracking • SPDX 2.3 is still the version most tooling emits in practice
ML-BOM (AI/ML Bill of Materials)	`{"bomFormat":"CycloneDX","components":[{"type":"machine-learning-model","modelCard":{...}}]}`	• CycloneDX extension for documenting AI/ML models, datasets, and training provenance, part of a broader "xBOM" family that also covers hardware (HBOM), services (SaaSBOM), and cryptography (CBOM) • helps assess bias, data-integrity, and model-security risk in AI systems
SWID	`<SoftwareIdentity name="openssl" version="3.0.8" .../>`	• ISO/IEC 19770-2 XML-based Software Identification tag • primarily used in US federal government device inventories • rarely adopted for general SBOM workflows compared to SPDX and CycloneDX

Table 2: SBOM Minimum Elements (2026 CISA Baseline)

CISA, the NSA, the FBI, and international partners replaced the 2021 NTIA baseline with the 2026 Minimum Elements for a Software Bill of Materials on July 29, 2026. It keeps the original principles (nested inventory, automation, known unknowns) but promotes several new fields to required status and renames a few others.

Element	Example	Description
Component Identifiers (PURL, CPE)	`pkg:npm/%40angular/core@17.3.0`	• At least one common lookup key is required, either a Package URL (PURL) or a CPE name • without one, automated vulnerability lookups produce high false-positive rates

The rest of this section is part of the full cheat sheet

Table 3: SBOM Generation and Validation Tools

These tools scan source code, build artifacts, container images, and filesystems to produce machine-readable SBOMs, and a separate class of tools checks that the result is well-formed. Generating SBOMs at build time, not post-facto, produces the most accurate results.

Tool	Example	Description
Syft	`syft alpine:latest -o cyclonedx-json`	• Anchore's open-source multi-ecosystem SBOM generator, still the most widely adopted open-source generator • supports Python, Go, Java, JavaScript, Rust, PHP, and more • outputs both CycloneDX and SPDX

The rest of this section is part of the full cheat sheet

Table 4: SBOM Generation Workflows

Integrating SBOM generation into CI/CD pipelines ensures SBOMs are produced consistently and tied to specific build artifacts rather than reconstructed after the fact.

Pattern	Example	Description
Build-time generation	`syft packages dir:. -o spdx-json > sbom.json` run in CI step	Generating SBOMs during the build, not post-build, captures the exact dependency set used and produces more accurate transitive dependency coverage than scanning deployed artifacts.

The rest of this section is part of the full cheat sheet

Table 1: SBOM Formats

Format	Example	Description
CycloneDX	`{"bomFormat":"CycloneDX","specVersion":"1.7","components":[...]}`	• OWASP flagship, Ecma-standardized SBOM format (ECMA-424, 2nd Edition, December 2025) built for application security and supply chain analysis • version 1.7 (October 2025) is the final release in the 1.x line, staying backward compatible with 1.4 through 1.6 • supports JSON, XML, and Protocol Buffers
SPDX	`{"spdxVersion":"SPDX-3.0.1","dataLicense":"CC0-1.0","creationInfo":{...}}`	• Linux Foundation project; the 2.2.1 line is codified as ISO/IEC 5962:2021, while the current 3.0.1 spec (April 2024, with a 3.1 release candidate) uses a new element-based model with optional profiles • excels at license compliance tracking • SPDX 2.3 is still the version most tooling emits in practice
ML-BOM (AI/ML Bill of Materials)	`{"bomFormat":"CycloneDX","components":[{"type":"machine-learning-model","modelCard":{...}}]}`	• CycloneDX extension for documenting AI/ML models, datasets, and training provenance, part of a broader "xBOM" family that also covers hardware (HBOM), services (SaaSBOM), and cryptography (CBOM) • helps assess bias, data-integrity, and model-security risk in AI systems
SWID	`<SoftwareIdentity name="openssl" version="3.0.8" .../>`	• ISO/IEC 19770-2 XML-based Software Identification tag • primarily used in US federal government device inventories • rarely adopted for general SBOM workflows compared to SPDX and CycloneDX

Table 2: SBOM Minimum Elements (2026 CISA Baseline)

Element	Example	Description
Component Identifiers (PURL, CPE)	`pkg:npm/%40angular/core@17.3.0`	• At least one common lookup key is required, either a Package URL (PURL) or a CPE name • without one, automated vulnerability lookups produce high false-positive rates

Table 3: SBOM Generation and Validation Tools

Tool	Example	Description
Syft	`syft alpine:latest -o cyclonedx-json`	• Anchore's open-source multi-ecosystem SBOM generator, still the most widely adopted open-source generator • supports Python, Go, Java, JavaScript, Rust, PHP, and more • outputs both CycloneDX and SPDX

Table 4: SBOM Generation Workflows

Integrating SBOM generation into CI/CD pipelines ensures SBOMs are produced consistently and tied to specific build artifacts rather than reconstructed after the fact.

Pattern	Example	Description
Build-time generation	`syft packages dir:. -o spdx-json > sbom.json` run in CI step	Generating SBOMs during the build, not post-build, captures the exact dependency set used and produces more accurate transitive dependency coverage than scanning deployed artifacts.