Software Bill of Materials (SBOM)

The National Telecommunications and Information Administration (NTIA) defines baseline components every SBOM must contain. Supplier Name identifies the author, while Component Name and Version String uniquely identify the software unit. A Unique Identifier like a Package URL (pURL) or CPE provides a machine-readable key. Dependency Relationship maps how components connect, and the Author and Timestamp establish provenance and recency.

An SBOM must articulate the hierarchical or graph-based relationships between components. It distinguishes between primary components (top-level software), transitive dependencies (indirectly included libraries), and runtime dependencies (required for execution). This mapping is critical for tracing a vulnerability like Log4Shell through deep dependency chains to determine actual exploitability.

Each component entry should include a cryptographic hash (e.g., SHA-256) to serve as a digital fingerprint. This allows consumers to verify that a retrieved artifact has not been tampered with or corrupted. By comparing the hash in the SBOM against the downloaded component, organizations can detect supply chain substitution attacks where a malicious actor replaces a legitimate library.

An SBOM aggregates the declared licenses (e.g., MIT, GPL-3.0) and concluded licenses (human-verified) for all components. This enables automated license policy enforcement during CI/CD pipelines. Organizations can instantly audit a product for copyleft or incompatible licenses, preventing legal risk before a software release.

A VEX document is a companion artifact to an SBOM that provides a machine-readable statement on the exploitability of a known vulnerability in a specific product context. It declares a status of Not Affected, Affected, Fixed, or Under Investigation. This eliminates false positives by allowing a supplier to assert that a component with a known CVE is not exploitable due to how it is used.