Related BOM Standards

SBOMs are only one part of a broader family of structured inventory artifacts. Companion BOM standards such as HBOM, SaaSBOM, AI/ML-BOM, and CBOM adapt the same basic idea to different layers of the digital supply chain, from hardware and cloud services to models and cryptography. Together, they support a more complete view of system composition, risk, and provenance.

HBOM — Hardware Bill of Materials

A hardware bill of materials (HBOM) lists the physical and logical components of a hardware product — integrated circuits, printed circuit boards, firmware, embedded software — and the relationships between them. The motivation is identical to software SBOMs: supply chain visibility, vulnerability tracking, and counterfeit detection.

CISA published an HBOM framework in November 2023 covering data format and use cases for hardware component transparency. ^[14] OMB M-26-05 explicitly elevated hardware supply chain risk as a priority alongside software, reflecting the recognition that software SBOMs alone do not capture the full attack surface of modern systems. ^[15] CycloneDX 1.4 and later support hardware component types natively, allowing HBOM and SBOM data to coexist in a single document or be linked across documents.

HBOM across roles

Producers of hardware products — device manufacturers, OEMs, embedded systems vendors — are increasingly expected to provide HBOMs to enterprise and government customers. Organizations selling into U.S. federal procurement channels and into EU CRA-regulated markets should anticipate HBOM requests alongside or integrated with SBOMs.

Consumers purchasing network equipment, medical devices, industrial control systems, or any product where the hardware supply chain affects security posture should begin including HBOM requests in procurement questionnaires. The CISA framework provides the vocabulary and structure for evaluating what is received.

Security teams dealing with incidents involving hardware components — firmware vulnerabilities, compromised components identified through threat intelligence — find HBOMs particularly valuable for scoping impact across a deployed fleet.

SaaSBOM — Software as a Service Bill of Materials

A SaaSBOM describes the components and services that make up a SaaS platform — not the source code of the platform itself (that is a software SBOM), but the external services, APIs, and third-party components the platform depends on at runtime. A SaaS product that depends on AWS Lambda for compute, Twilio for communications, Stripe for payments, and Elasticsearch for search has a SaaSBOM that captures those dependencies.

CycloneDX 1.4 introduced the service component type to support SaaSBOM use cases. ^[16] SPDX 3.0’s service profile covers similar ground. The concept is directly relevant to OMB M-26-05’s provision that cloud service providers should be able to produce SBOM data describing the runtime production environment on request from federal customers.

SaaSBOM across roles

SaaS producers face a specific complexity: their service’s component picture changes continuously, potentially with every deployment. SaaSBOM generation at the infrastructure level — capturing runtime service dependencies from IaC manifests, service mesh telemetry, or cloud provider APIs — is an emerging practice without fully mature tooling. Producers should begin with what is tractable: a documented inventory of third-party service dependencies and their security posture, updated at least quarterly.

SaaS consumers — which, as noted in the receiver’s perspective section of this project, includes the majority of modern organizations — should understand that the SaaSBOM is the artifact that answers “what is my SaaS vendor actually running under the hood?” For federal customers, the right to request this information under M-26-05 is explicit. For commercial customers, the question can be raised through vendor security questionnaires and should be a normal part of due diligence for critical SaaS providers.

Risk and compliance teams evaluating SaaS vendor risk often focus on the top-level vendor’s SOC 2 or ISO 27001 certification without examining what that vendor’s own supply chain looks like. A SaaS provider who depends on a vulnerable third-party service inherits that vulnerability. SaaSBOM data surfaces the “fourth-party” risk that is invisible in most vendor security assessments.

AI/ML-BOM — Artificial Intelligence and Machine Learning Bill of Materials

An AI/ML-BOM captures the components that make up a machine learning system: the base model or models, training data references, fine-tuning datasets, preprocessing pipelines, inference-time dependencies, and runtime serving infrastructure. As AI-enabled products proliferate across every industry, the supply chain risks associated with models — data poisoning, model tampering, adversarial manipulation of fine-tuning datasets — require the same kind of component transparency that software supply chain attacks drove for code.

CycloneDX 1.5 and later support AI/ML component types, including machineLearningModel and related metadata fields. ^[17] NIST’s AI Risk Management Framework (AI RMF) and the companion NIST AI 600-1 (for generative AI) identify supply chain transparency as a risk management practice. ^[18] The EU AI Act’s transparency and conformity assessment obligations for high-risk AI systems will increasingly require documentation that resembles an AI/ML-BOM. ^[19]

AI/ML-BOM across roles

Producers of AI-enabled products — whether building on foundation models from third parties, training custom models, or fine-tuning open weights models — should begin documenting model provenance, training data lineage, and inference-time dependencies now. This documentation is the foundation of any future AI/ML-BOM and is increasingly requested in enterprise procurement.

Consumers integrating AI features from third-party vendors face a specific version of the SBOM receiver problem: the model may change without a corresponding version change in the product. Establishing contractual expectations around model version disclosure and change notification is a near-term procurement priority for any organization deploying AI in a regulated or high-stakes context.

Security teams assessing AI-enabled products should include model provenance in scope. The supply chain risk profile of a product using a model downloaded from an unverified source is materially different from one using a model with documented provenance, integrity verification, and a disclosed training data lineage.

CBOM — Cryptographic Bill of Materials

A CBOM catalogs the cryptographic algorithms, protocols, and key lengths used throughout a software or hardware system. It is distinct from an SBOM (which captures software components) in that it focuses specifically on the cryptographic layer — which cipher suites are in use for TLS, which algorithms are used for signing and hashing, which key management approaches are deployed.

The primary driver for CBOM today is the post-quantum migration. NIST finalized its first post-quantum cryptography standards in 2024, and organizations across every sector now face the task of identifying everywhere classical public-key cryptography is in use before it can be replaced. ^[20] Without a CBOM, that inventory is a manual, error-prone process. With one, the exposure surface is enumerable.

CycloneDX 1.6 added the cryptoProperties field to support CBOM natively. ^[21] IBM has been a notable contributor to the CBOM specification and has tooling to generate CBOMs from codebases and containers.

CBOM across roles

Producers should begin generating CBOMs for products in which cryptographic agility matters — network devices, security appliances, certificate management systems, devices with long deployed lifetimes, and any product operating in a regulated environment where cryptographic requirements are audited. The post-quantum migration timeline makes this urgent: products being deployed now will still be in service when quantum-capable adversaries arrive.

Consumers purchasing products with long deployment lifetimes — critical infrastructure, healthcare devices, financial systems — should ask for CBOMs alongside SBOMs to understand the cryptographic exposure of what they are buying and plan remediation timelines for the post-quantum transition.

Risk and compliance teams will increasingly encounter CBOM requirements in federal procurement (CISA and NSA guidance on post-quantum migration references component-level cryptographic inventory) and in standards like FIPS 140-3 compliance assessments. ^[22]

Designing for the full BOM family

The software industry spent years building SBOM tooling that handles only software. Adding hardware, service, AI, and cryptographic components as afterthoughts has proved painful everywhere it has been attempted. The practical guidance for anyone designing or procuring an SBOM management system today is direct: design the data model and the tooling stack to hold any BOM type alongside the others from the start.

CycloneDX 1.7 supports all of the BOM types described here — SBOM, HBOM, SaaSBOM, AI/ML-BOM, CBOM — within a single document model and with a unified component taxonomy. ^[23] SPDX 3.0 introduces profile-based extensions for several similar use cases. ^[24] Dependency-Track, the leading open source SBOM management platform, has active work toward multi-BOM-type support. ^[25]

The Transparency Exchange API (TEA), currently in beta under ECMA TC54, is designed to handle the full family of BOM artifacts — not just software SBOMs — and to support automated discovery and retrieval from producers. ^[26] Organizations building SBOM receiving infrastructure should watch TEA closely, as it is likely to become the standard exchange mechanism for the entire BOM family.

A compound product — one that includes hardware, runs software, exposes a SaaS interface, uses AI features, and encrypts data in transit — has all five BOM types applicable simultaneously. That is not a hypothetical: it describes a modern medical device, a smart industrial controller, or an enterprise network appliance. The organizations that have invested in a unified BOM data model will have a significant advantage when regulators, customers, and incident responders begin asking for the full picture.