Software Bill of Materials (SBOM)

● standardA Software Bill of Materials (SBOM) is a machine-readable inventory of every software component a build depends on — packages, libraries, their versions, suppliers, and how they relate to each other. It answers what is in this build?

◆ practitionerIt does not answer what cryptography is inside it? — that is the CBOM module's job, one layer up. An SBOM lists software; a CBOM extends that list with algorithm, key size, protocol, and quantum-vulnerability fields the SBOM has no place for. Keep the two separate: this module is the software inventory, not the crypto one.

● standardSPDX (Linux Foundation; standardized as ISO/IEC 5962:2021) grew out of license-compliance tooling and has the deeper license/provenance model. CycloneDX (OWASP; standardized as ECMA-424) grew out of application-security tooling and is the more extensible object model — SaaSBOM, HBOM, ML-BOM and VDR/VEX are all sibling BOM types built on the same schema.

◆ practitionerNeither format has a cryptography object model built in for general use. CycloneDX does have a crypto-specific extension (assetType: cryptographic-asset) — that extension, and the SPDX-vs-CycloneDX trade-off for a crypto inventory specifically, is covered in the CBOM module, not repeated here. Likewise, CycloneDX's own cross-tool algorithm/curve naming registry is covered in the CycloneDX Cryptography Registry module.

● standardNTIA's 2021 Minimum Elements for a Software Bill of Materials defines seven required fields per component: Supplier Name, Component Name, Version, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp. Two of the seven — author and timestamp — live at the document level, not per component.

● standardCISA finalized a successor on 29 July 2026 — the 2026 Minimum Elements for a Software Bill of Materials, v2.1 — co-authored with NSA, FBI, and 15 international partner cyber agencies. It keeps all seven of the above and adds ten more; see the next section for what changed and why.

● standardThe seven elements above went unchanged for four years while SBOM tooling matured well past what they were designed for. The 2026 update is a strict superset — nothing from 2021 was removed or redefined — adding ten new required elements: seven at the document level (SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Tool Name, SBOM Tool Version, SBOM Version, and SBOM Generation Context) and three per component (Component Hash Algorithm, Component Hash Value, and Component License). Eight more existing elements — including SBOM Author, Component Producer, Component Identifiers, and Component Version — gained clarified scope without changing what they require.

◆ practitionerReal-world tooling hasn't caught up yet. We checked seven generators' actual current default output (not the format's theoretical capability) against these ten elements: none is fully 2026-compliant out of the box. npm's native npm sbom comes closest at 9 of 10 fields (missing only the signature); pip-audit trails furthest behind at 2 of 10, and still emits the older CycloneDX 1.4 schema. Two gaps are universal across every tool checked: none sign the SBOM automatically, and SBOM Generation Context has no clean mapping in any of them. Treat this as an August 2026 snapshot, not a fixed verdict — SBOM generators are actively adding fields as adoption of the 2026 baseline spreads, so expect these numbers to climb; re-check a tool's current release before relying on it for a real compliance claim.

● standardAn SBOM lists what is present; it says nothing about whether a listed component's known vulnerabilities are actually reachable in this product. VEX (Vulnerability Exploitability eXchange) — Profile 5 of OASIS CSAF 2.0 — closes that gap with a machine-readable affected / not affected / fixed / under investigation statement per CVE per product.

◆ practitionerWithout VEX, a CVE in a widely-used component (a compression library, a crypto library) fires an alert for every product that merely lists it in an SBOM, regardless of whether the vulnerable code path is ever called. VEX turns that into a triage decision instead of a fire drill.

● standardUS Executive Order 14028 (May 2021) requires software vendors selling to the federal government to provide an SBOM — the requirement that produced NTIA's minimum-elements work above. The EU Cyber Resilience Act (Regulation EU 2024/2847) requires manufacturers of products with digital elements to maintain an SBOM covering top-level dependencies, with the main obligations applying from 11 December 2027.

◆ practitionerNeither mandate is PQC-specific — they are general software supply-chain requirements. The reason a PQC migration program cares is downstream: an SBOM built to satisfy EO 14028 or the CRA is exactly the existing data source a crypto-discovery effort should integrate rather than duplicate.

◆ practitionerAn SBOM is Phase 1 discovery input, not a Phase 2 output: it is one of the existing data sources a crypto-discovery effort should cross-reference rather than rebuild from scratch. Skipping that cross-reference — building a CBOM without linking it back to SBOM dependency chains — is a named common failure in PQC migration programs.

◆ practitionerTwo different next steps, two different modules:

• Need to know what cryptographic algorithms, keys, and certificates a component uses? That's the CBOM module.
• Need to resolve the same mechanism named differently across an HSM, a certificate, and a library string? That's the CycloneDX Cryptography Registry module.