What Is xBOM? Every Type of Bill of Materials Explained

xBOM is informal shorthand for the whole family of bills of materials, where the "x" stands for whatever is being inventoried: software (SBOM), services (SaaSBOM), hardware (HBOM), operations (OBOM), manufacturing (MBOM), machine learning (ML-BOM or AIBOM) and cryptography (CBOM). No standard defines "xBOM" itself. The types are defined inside two formats, CycloneDX and SPDX 3.

When a procurement team asks for "an xBOM", they are really asking for one or more specific inventories, each answering a different question in a format a tool can validate. This guide covers every member of the family, which format defines it, how vulnerability documents differ, which BOMs each kind of team needs, and a walkthrough with the standards bodies' own open source tools. If you are new to the basic idea, start with our explainer on what a software bill of materials is and come back.

Key takeaways

• "xBOM" is a nickname, not a standard. The real types live in CycloneDX (standardised as ECMA-424) and SPDX 3.0.1 profiles.
• CycloneDX publishes a capability page for SBOM, SaaSBOM, HBOM, OBOM, MBOM, ML-BOM, CBOM, VDR, VEX, BOV, attestations (CDXA) and BOM-Link. There is no CycloneDX page for a "KBOM" or a "data BOM"; those are built from general CycloneDX features.
• SPDX 3.0.1 does not use the "xBOM" naming at all. It defines nine profiles (Core, Software, Security, Licensing, Dataset, AI, Build, Lite and Extension), and you compose them to describe the same things.
• VDR, VEX and BOV describe vulnerabilities, not components. They point at a BOM rather than replacing it.
• The BOM types (what is inventoried) are a different axis from the SBOM lifecycle types (when and how the inventory was captured: design, source, build, analyzed, deployed, runtime).
• Regulation today asks for SBOMs. The 2026 CISA minimum elements, the FDA premarket guidance and the EU Cyber Resilience Act all centre on software. Everything else in the family is optional unless a contract or sector rule says otherwise, though AI guidance is moving fastest.
• One product usually needs several linked BOMs. CycloneDX links them with BOM-Link URNs.

Is "xBOM" a standard term?

No. Search the CycloneDX specification, the ECMA-424 standard text, the SPDX 3.0.1 model or the CISA SBOM pages and you will not find "xBOM" defined as a document type. It is industry shorthand, used by vendors, conference speakers and analysts to mean "every kind of BOM, not just the software one". Some people write it "XBOM".

What the standards do define is the set of things a BOM can describe. The CycloneDX project lists each use case as a separate capability on its site. ECMA-424, the Ecma International standard that formalises CycloneDX, says on Ecma's own page that it covers "software and hardware components, services, dependencies, vulnerabilities, cryptographic artefacts, machine learning models" and more, serialised as JSON. The first edition of ECMA-424 was published in June 2024, and the current edition listed on Ecma's site defines CycloneDX v1.7. Ecma also lists an ISO/IEC number for it, DIS 27055, which signals that the standard is on its way through ISO.

SPDX takes a different route. Instead of naming BOM types, SPDX 3.0.1 defines "profiles", which its conformance section describes as compliance points. The Core profile is mandatory and the rest are optional. A document that uses the Software and Security profiles is, in effect, an SBOM with vulnerability data. A document that adds the AI profile is what others would call an AIBOM.

So when someone says "send us your xBOM", the useful reply is a question: which inventory, in which format and version?

The BOM family at a glance

The table below is the short version. Each row is expanded in the next section.

Two things stand out. First, CycloneDX gives almost every type a named home in its schema, which is why the "xBOM" vocabulary grew up around it. Second, SPDX covers software, security, licensing, build, AI and datasets very thoroughly, but does not try to describe hardware, services or cryptography as separate concepts.

What each BOM type records

SBOM: the software inventory

The CycloneDX SBOM capability page describes the SBOM as an inventory of "software components and services and the dependency relationships between them". That last part is the one teams skip. A flat list of packages tells you what is present; the dependency graph tells you how a vulnerable library got there and which top level dependency you have to change to remove it.

The baseline content of an SBOM is now set by the CISA "2026 Minimum Elements for a Software Bill of Materials", published on 29 July 2026 with a long list of co-authoring agencies, which updates and replaces the 2021 NTIA minimum elements. It adds new data fields, among them SBOM Author Signature, SBOM Tool Name and Version, SBOM Generation Context, Component Hash Value and Algorithm, and Component License. Our post on the CISA 2026 minimum elements update covers the field changes in detail, so we will not repeat them here.

In CycloneDX an SBOM is a components array tied together by a dependencies array. In SPDX 3.0.1 it is a document conforming to the Core and Software profiles.

SaaSBOM: services and data flows

A SaaSBOM inventories services rather than packages. The CycloneDX capability page says it captures "service endpoints, dependencies, data flows, and classifications" for cloud native systems. In the CycloneDX 1.7 schema, a service carries a provider, endpoints, an authenticated flag, a trust zone, licences and a data array where each entry states a flow direction (inbound, outbound, bi-directional or unknown) and a classification.

The point of a SaaSBOM is to make a hosted product reviewable even though the customer never receives a binary. It answers "which third party APIs does this service call, and what class of data crosses each boundary?" That is also why the 2026 CISA document notes that SaaS "may require additional elements" beyond the SBOM minimum. Our explainer what is a SaaSBOM and does your service inventory need one goes through the decision.

HBOM: physical parts and firmware

An HBOM lists the physical parts in a device: processors, boards, radios, storage and the firmware those parts run. CycloneDX describes it as an inventory of hardware components "for IoT, ICS, and other types of embedded and connected devices". In the schema, hardware shows up as components of type device, device-driver and firmware. SPDX 3.0.1 has no hardware profile.

Our HBOM series, starting with the HBOM complete guide and HBOM vs SBOM, covers the rest, so this post only places HBOM in the family.

OBOM: what is actually running

An Operations BOM is a full stack inventory of a running environment. CycloneDX's page describes it as covering "runtime environments, configurations, and additional dependencies" in staging or production. In practice that means the operating system and its packages, the container runtime and images, the configuration that changes behaviour, and links to the SBOMs of the applications and the HBOM of the host.

The CycloneDX 1.7 schema's operations lifecycle phase describes exactly this: a BOM representing inventory that is running, which "will generally encompass multiple SBOMs describing the applications and operating system, along with HBOMs describing the hardware". An OBOM is therefore usually a composition of other BOMs plus the glue that says how they are deployed.

MBOM: how it was made

The Manufacturing BOM is the least understood type. In CycloneDX it records "declared and observed formulation for reproducibility throughout the product lifecycle". The schema field is formulation, which the 1.7 schema describes as how any referenceable object "was created, assembled" and so on, and which contains formulas, workflows, tasks, steps, commands, workspaces and triggers.

An SBOM tells you what is in the box; an MBOM tells you how the box was filled. CycloneDX notes that formulation can be shared separately from the main inventory to protect sensitive detail. SPDX 3.0.1 covers a narrower slice of the same ground with its Build profile, which records build start and end times, build types and parameters.

ML-BOM and AIBOM: models and the data behind them

CycloneDX calls this type ML-BOM, and its page title reads "Machine Learning Bill of Materials (AI/ML-BOM)". It represents "models, datasets, and their dependencies", including dataset provenance and training methodology. In the schema, a model is a component of type machine-learning-model with a modelCard object that holds model parameters, quantitative analysis (performance metrics) and considerations such as users, use cases, limitations, fairness assessments and environmental impact.

SPDX 3.0.1 has a dedicated AI profile whose summary says it provides "a standardized way of documenting and sharing information about AI software packages". Its central class is AIPackage, with properties such as autonomy type, domain, energy consumption (for training, fine tuning and inference), hyperparameters, limitations, metrics, model explainability, safety risk assessment, standard compliance, type of model and use of sensitive personal information.

"AIBOM" is the more common name elsewhere. The OWASP GenAI Security Project runs an AIBOM initiative that publishes the open source OWASP AIBOM Generator. Our post on what AI bills of materials are covers the motivation.

CBOM: cryptographic assets

A CBOM inventories cryptography. CycloneDX describes it as covering "algorithms, keys, certificates, and their relationships to software components", with an eye on the move to quantum safe cryptography. In the schema, a component of type cryptographic-asset carries cryptoProperties, whose assetType is one of algorithm, certificate, protocol or related-crypto-material. Algorithm properties include the primitive (for example ae for authenticated encryption, signature, hash, kem), parameter set, curve, mode, padding, crypto functions and both classical and NIST quantum security levels.

An SBOM tells you a TLS library is present; a CBOM tells you which algorithms and key sizes your code actually uses with it. See what is a CBOM and how is it different from an SBOM for the background.

Data BOM: datasets as first class components

There is no CycloneDX capability page called "data BOM", but the schema treats data as a component type in its own right. A component of type data carries a data array (componentData) with a type, name, contents, classification, sensitive data notes, graphics, description and a governance block that names custodians, stewards and owners.

SPDX 3.0.1 is more explicit here. Its Dataset profile "provides additional metadata, based on Software Profile, that is useful for datasets", built around a DatasetPackage class. If your main concern is documenting training and evaluation data, the SPDX Dataset profile is the most structured option today, and it composes naturally with the AI profile.

KBOM: an informal Kubernetes inventory

KBOM, short for Kubernetes bill of materials, is the most informal member of the family. Neither CycloneDX nor SPDX defines a KBOM type, and CycloneDX has no capability page for it. The term comes from open source tooling that inventories a cluster: control plane version, nodes and their operating systems, installed add-ons, and the container images running in each namespace.

If you need one, the honest framing is that a KBOM is an OBOM scoped to a Kubernetes cluster. You can express it in CycloneDX with components of type platform, operating-system and container, an operations lifecycle phase, and BOM-Links out to the SBOMs of each image. Treat any "KBOM format" as a tool's own convention rather than a standard.

Which types are first class in CycloneDX, and which are SPDX 3 profiles?

The two formats were designed with different philosophies, and that is visible in how they handle the family.

CycloneDX is one schema with many optional sections. The same JSON document can carry components of any type, services, formulation, vulnerabilities and declarations (attestations). The named BOM types are use cases of that one schema. The 1.7 schema's component type enumeration is the clearest list: application, framework, library, container, platform, operating-system, device, device-driver, firmware, file, machine-learning-model, data and cryptographic-asset.

SPDX 3.0.1 is a graph of elements, and profiles decide which classes and properties you may use. The conformance section lists the nine profiles and states that "The Core Profile is mandatory. All others are optional." A tool that claims Software profile conformance does not have to support the AI or Dataset profiles.

If you need hardware, services or cryptography, CycloneDX holds everything in one place. If your needs are software, licensing, AI and datasets, SPDX 3 covers them in depth, and its Lite profile captures the minimum needed for licence compliance. Many organisations produce both.

VDR, VEX and BOV: documents about vulnerabilities, not components

Three members of the family are often listed next to the BOM types, but they answer a different question. A BOM says "what is in this product". These say "what is known about vulnerabilities in it".

The CycloneDX VDR page says VDRs, also called Vulnerability Advisory Reports, communicate "known and unknown vulnerabilities affecting components and services", can state how complete the vulnerability intelligence is, and align with ISO/IEC 29147 on vulnerability disclosure. The VEX page says VEX conveys "the exploitability of vulnerable components in the context of the product in which they're used". The BOV page describes a way to exchange vulnerability intelligence between systems, including severities, risk ratings and remediation details.

CISA's SBOM page describes VEX as "a form of a security advisory that indicates whether a product or products are affected by a known vulnerability or vulnerabilities". In CycloneDX 1.7, the analysis.state values are resolved, resolved_with_pedigree, exploitable, in_triage, false_positive and not_affected, and a not_affected statement can carry a justification such as code_not_present, code_not_reachable, requires_configuration, requires_dependency, requires_environment, protected_by_compiler, protected_at_runtime, protected_at_perimeter or protected_by_mitigating_control. OpenVEX, maintained under the OpenVEX GitHub organisation, defines its own status values and requires either a justification or an impact statement for any not_affected status.

A VEX is only useful if it can point at a specific component in a specific product version, which is why VEX documents and BOMs are usually separate files linked by identifiers. Our VEX guide covers how to write and consume them; later posts in this series compare the VEX formats field by field.

BOM types versus SBOM lifecycle types

There is a second classification that people mix up with the first. "Design, source, build, analyzed, deployed, runtime" are not kinds of BOM. They are kinds of SBOM, sorted by when and how the data was captured.

CISA's "Types of Software Bill of Material (SBOM) Documents", published on 21 April 2023 and drafted by a community working group that CISA facilitated, defines six types and states that the list "is not intended to be tightly tied to the software lifecycle". SPDX 3.0.1 adopts the same six as the SbomType vocabulary: design, source, build, analyzed, deployed and runtime. CycloneDX 1.7 records the same idea in metadata.lifecycles with seven pre-defined phases: design, pre-build, build, post-build, operations, discovery and decommission.

The mapping between CISA and CycloneDX is ours, made by reading both definitions; neither document publishes it. The 2026 CISA minimum elements turned this axis into a required field. "SBOM Generation Context" is defined as "the relative software lifecycle phase and data available at the time the SBOM author generated the SBOM", and CISA says general labels such as "before build", "build" and "after build" satisfy it.

The two axes combine. You can have a build time SBOM and a runtime SBOM of the same product, or a design time AIBOM and a deployed AIBOM. Our posts on the six SBOM types and source, build, analyzed and deployed SBOMs cover the trade-offs of each.

One product, many BOMs: how the types link together

A real product rarely fits in one BOM. A medical imaging appliance might need an HBOM for the device, an SBOM for the application, a CBOM for the crypto it uses to protect patient data, an ML-BOM for the classification model, a SaaSBOM for the cloud services it calls, and a stream of VEX documents as new vulnerabilities appear. Different teams own each one, they change at different speeds, and some are more sensitive than others.

CycloneDX handles this with BOM-Link. The BOM-Link page states it is a "formally registered URN, governed by IANA, and compliant with RFC-8141", with the syntax urn:cdx:serialNumber/version#bom-ref. The serial number is the BOM's own unique identifier and must conform to RFC 4122, the version defaults to 1, and the optional fragment points to a specific component, service or vulnerability inside that BOM. That gives you two kinds of link:

• A document link, such as urn:cdx:7d1f2a33-0c55-4c8e-9a62-5b2f6c9e0d11/3, which says "version 3 of that BOM".
• An element link, such as urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/1#pkg:npm/express@4.21.2, which says "this component inside version 1 of that BOM".

You place document links in externalReferences, using a reference type that says what the other document is. The CycloneDX 1.7 schema's external reference types include bom, exploitability-statement, vulnerability-assertion, attestation, formulation, model-card, threat-model, risk-assessment and many more. Element links are what a VEX uses in its affects field to name the exact component it is talking about.

Here is a minimal product BOM that holds several types at once: one library (SBOM), one model (ML-BOM), one algorithm (CBOM) and one service (SaaSBOM), with links out to a separate VEX and to the HBOM of the hardware it ships on. It validates against the CycloneDX 1.7 JSON schema (bom-1.7.schema.json); we checked it with a JSON Schema validator before publishing.

{
  "$schema": "http://cyclonedx.org/schema/bom-1.7.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-23T09:00:00Z",
    "lifecycles": [{ "phase": "build" }],
    "component": {
      "type": "application",
      "bom-ref": "app",
      "name": "claims-portal",
      "version": "4.2.0"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/express@4.21.2",
      "name": "express",
      "version": "4.21.2",
      "purl": "pkg:npm/express@4.21.2"
    },
    {
      "type": "machine-learning-model",
      "bom-ref": "model-triage",
      "name": "claims-triage-classifier",
      "version": "2026.10"
    },
    {
      "type": "cryptographic-asset",
      "bom-ref": "crypto-aes256gcm",
      "name": "AES-256-GCM",
      "cryptoProperties": {
        "assetType": "algorithm",
        "algorithmProperties": {
          "primitive": "ae",
          "parameterSetIdentifier": "256",
          "mode": "gcm"
        }
      }
    }
  ],
  "services": [
    {
      "bom-ref": "svc-payments",
      "name": "payments-api",
      "endpoints": ["https://payments.example.com/v1"],
      "authenticated": true,
      "data": [{ "flow": "outbound", "classification": "PII" }]
    }
  ],
  "externalReferences": [
    {
      "type": "exploitability-statement",
      "url": "urn:cdx:b5f2c6a1-6a1e-4d4f-9c1e-2f0f5f1e7a10/1",
      "comment": "VEX for claims-portal 4.2.0, published separately"
    },
    {
      "type": "bom",
      "url": "urn:cdx:7d1f2a33-0c55-4c8e-9a62-5b2f6c9e0d11/3",
      "comment": "HBOM of the appliance this build ships on"
    }
  ],
  "dependencies": [
    {
      "ref": "app",
      "dependsOn": ["pkg:npm/express@4.21.2", "model-triage", "crypto-aes256gcm", "svc-payments"]
    }
  ]
}

And here is the separate VEX it points to. Its serial number matches the BOM-Link above, and its affects entry uses an element link back into the product BOM. It also validates against CycloneDX 1.7. The vulnerability identifier is a placeholder, because this example is about structure, not about any real advisory.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:b5f2c6a1-6a1e-4d4f-9c1e-2f0f5f1e7a10",
  "version": 1,
  "metadata": { "timestamp": "2026-10-23T09:30:00Z" },
  "vulnerabilities": [
    {
      "id": "EXAMPLE-2026-0001",
      "source": { "name": "Example advisory feed" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable function is never called by claims-portal."
      },
      "affects": [
        { "ref": "urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/1#pkg:npm/express@4.21.2" }
      ]
    }
  ]
}

The product BOM changes per release; the VEX changes whenever a vulnerability is triaged. Keeping them separate lets you publish a new VEX without re-issuing the SBOM. The same pattern suits an HBOM owned by a hardware team or a CBOM only the security team should see, which is the "targeted access" the BOM-Link page describes.

SPDX 3.0.1 links through globally unique element identifiers and external maps, and its VEX statements are Security profile relationships such as VexNotAffectedVulnAssessmentRelationship rather than a vulnerabilities array.

Which BOMs does your team need?

This is the decision table people ask for. "Required" means a regulator or common contract term asks for it today; "useful" means it answers a question you will be asked; "rarely" means it does not fit the product.

Everyone needs an SBOM and a way to answer vulnerability questions about it, which is VEX. Every other type earns its place only when it answers a question someone is actually asking you.

What regulators actually ask for today, and what is optional

Here is where regulation stands as of October 2026, from the primary documents.

Notice what is missing. No regulation we checked requires an HBOM, OBOM, MBOM, KBOM, CBOM or SaaSBOM by name. CBOMs come up in post-quantum migration planning and in national security guidance, and HBOMs in procurement and sector rules, but as of this writing they are contract or sector expectations rather than horizontal legal requirements. The 2026 CISA document is explicit that it does not create new requirements; it refines how organisations should generate and request SBOMs.

The CISA document names AI and SaaS as areas needing more than the SBOM minimum, and AI guidance already exists. If you build AI products, expect AIBOM requests to become routine first.

Walkthrough: produce, validate and link several BOM types with open source tools

This walkthrough uses tools from the CycloneDX project's own GitHub organisation: cdxgen for generation and the CycloneDX CLI for validation and merging. Features below come from each tool's README. Install them in a scratch environment first and read what each command collects before you run it on a production host.

Step 1. Install cdxgen. The cdxgen README shows a global npm install with install scripts disabled:

npm install -g @cdxgen/cdxgen --ignore-scripts --min-release-age=2
cdxgen --version

Step 2. Generate the SBOM for a repository. From the project root, recurse into all supported ecosystems and write a CycloneDX JSON file. cdxgen's default specification version is 1.7, and --spec-version lets you target 1.6 if a consumer cannot read 1.7 yet.

cdxgen -r -o sbom.json .
# For a consumer that only reads 1.6:
cdxgen -r -o sbom-1.6.json --spec-version 1.6 .

For a single ecosystem, pass a project type, for example cdxgen -t js -o sbom.json for a JavaScript project or cdxgen -t java -o sbom.json for Java.

Step 3. Generate the specialised BOMs where they apply. The cdxgen README lists dedicated commands for several family members. Run only the ones that answer a real question for you.

# AI/ML BOM: prompt files, AI services, MCP configs and model metadata
aibom .

# CBOM-oriented defaults (cryptographic assets)
cbom -o cbom.json .

# SaaSBOM-oriented defaults (services and endpoints)
saasbom -o saasbom.json .

# OBOM of the current host or a Linux image (alias for cdxgen -t os)
obom -o obom.json

The README is specific about scope: the CBOM covers Java keystores and certificates plus JavaScript and TypeScript source level algorithm inventory; the SaaSBOM covers Java, Python, JavaScript, TypeScript and PHP projects; and the OBOM covers Linux container images and hosts running Linux or Windows. It also documents an hbom command for supported live hosts. If you need an HBOM, read our step by step CycloneDX HBOM guide first, because hardware probes need elevated access on the machine you run them on.

Step 4. Validate every file against the schema. The CycloneDX CLI validate command defaults to v1.7 and can fail a build on errors:

cyclonedx validate --input-file sbom.json --input-version v1_7 --fail-on-errors
cyclonedx validate --input-file cbom.json --input-version v1_7 --fail-on-errors

Validation catches structural mistakes such as an invented component type. It will not tell you whether the inventory is complete; that is a separate quality question.

Step 5. Decide: merge or link. The CycloneDX CLI can merge files, including a hierarchical merge that nests each input under a named parent:

cyclonedx merge --input-files sbom.json saasbom.json \
  --output-file product-bom.json \
  --hierarchical --name claims-portal --version 4.2.0

Merge when one audience needs everything in one file. Link when the parts have different owners, different update rates or different sensitivity. To link, record each file's serialNumber and version, and add externalReferences entries using the urn:cdx:serial/version form shown earlier.

Step 6. Publish VEX separately. Write VEX statements in their own document, with affects pointing back to the product BOM by element link, and update them as your triage changes. Validate them with the same cyclonedx validate command.

Step 7. Wire it into CI. A minimal GitHub Actions job that builds and validates the SBOM on every push looks like this:

name: bom
on: [push]
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm install -g @cdxgen/cdxgen --ignore-scripts
      - run: cdxgen -r -o sbom.json .
      - run: |
          curl -sSL -o cyclonedx https://github.com/CycloneDX/cyclonedx-cli/releases/latest/download/cyclonedx-linux-x64
          chmod +x cyclonedx
          ./cyclonedx validate --input-file sbom.json --input-version v1_7 --fail-on-errors
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

Pin the CLI to a specific release in a real pipeline rather than latest, and check the release asset name for your runner's architecture on the CycloneDX CLI releases page.

Where Safeguard fits

Safeguard's fit here is strong for SBOMs, VEX and attestations, partial for AIBOMs, and absent for several other family members, so it is worth being precise.

SBOM generation and analysis is generally available: Safeguard produces SPDX (JSON, XML and RDF) and CycloneDX (JSON and XML), offers more than 30 export formats including CSV, Excel and PDF, has a Deep Analysis option powered by Griffin, and can scan continuously on push, on a schedule or on release. CSAF and VEX upload is generally available, so a VEX you write with the steps above, or one a supplier sends you, can be applied to findings. Attestation and signing is generally available with SLSA, Sigstore (Fulcio and Rekor keyless), in-toto and X.509, plus Kubernetes admission control. License compliance is generally available, with SPDX expression parsing, policy and NOTICE and attribution generation. Third-party risk management (TPRM) is generally available and lets you onboard vendors and request SBOMs, projects or products from them. The Portal is generally available as the publish, share and SBOM management surface; the Trust Center inside it is in early access.

AI-BOM discovery is in early access. It inventories AI assets across code (SDK imports), cloud (SageMaker, Bedrock and Vertex), SaaS (shadow AI) and vector databases, and produces an ML-BOM in CycloneDX and the SPDX AI profile.

Safeguard does not generate HBOMs, CBOMs, OBOMs, MBOMs, KBOMs, SaaSBOMs or dataset BOMs, does not author VDR or BOV documents, does not produce SWID or CoSWID tags, and does not run a Transparency Exchange API server. For those, use the open source tools above, and use Safeguard for the software inventory, the vulnerability and VEX workflow, attestations and supplier SBOM collection that tie them together.

Common mistakes

Treating "xBOM" as a deliverable. A contract clause that says "the supplier shall provide an xBOM" is unenforceable in practice. Name the type, the format and the version, for example "CycloneDX 1.6 or later SBOM in JSON, plus VEX for every vulnerability the buyer reports".

Confusing BOM types with SBOM lifecycle types. "We need a runtime BOM" could mean an OBOM or a runtime SBOM. Ask which inventory and which generation context.

Putting VEX inside the SBOM and never updating it. CycloneDX allows vulnerabilities in the same document, which is fine for a snapshot. For ongoing triage, publish VEX separately and link it, or the SBOM becomes stale the day after release.

Inventing component types. Tools and hand written files sometimes use types such as ai-model or crypto. Those fail CycloneDX schema validation; the real values are machine-learning-model and cryptographic-asset. Validate every file.

Breaking BOM-Links by reusing serial numbers. A BOM-Link is only as good as the serial number and version behind it. Generate a new version number for every change and keep the serial number stable for the same logical BOM; never reuse a serial number for a different product.

Assuming SPDX and CycloneDX map one to one. SPDX 3.0.1 has no home for hardware, services or cryptographic assets, and CycloneDX's licensing model is less expressive than SPDX's. Converting between them loses data in both directions; the field by field post in this series covers exactly what.

Generating a BOM nobody asked for. A CBOM nobody reads still costs effort and drifts. Start from the question each BOM answers, and never promise a customer a "KBOM format", which does not exist.

Forgetting the generation context and tool fields. Under the 2026 CISA minimum elements, SBOM Generation Context, Tool Name and Tool Version are now baseline fields. CycloneDX carries them in metadata.lifecycles and metadata.tools; make sure your generator fills them.

FAQ

What does xBOM stand for?

The "x" is a placeholder for whatever is being inventoried: software, SaaS, hardware, operations, manufacturing, machine learning or cryptography. xBOM is an informal collective name for the family, not a document type defined by any standard.

Is AIBOM the same as ML-BOM?

In practice, yes. CycloneDX calls its capability ML-BOM and titles the page "AI/ML-BOM"; OWASP and most regulators say AIBOM. SPDX 3.0.1 covers the same ground with its AI profile and Dataset profile.

Does SPDX support HBOM or CBOM?

Not as dedicated concepts. SPDX 3.0.1 defines nine profiles (Core, Software, Security, Licensing, Dataset, AI, Build, Lite and Extension). There is no hardware or cryptography profile. Use CycloneDX for HBOMs and CBOMs.

What is the difference between an SBOM and an OBOM?

An SBOM lists the software components of a product. An OBOM lists what is running in an environment: operating systems, runtimes, configuration and the products deployed there, usually by referencing their SBOMs and the HBOM of the host.

Is a VEX a type of SBOM?

No. A VEX describes whether a product is affected by specific vulnerabilities. It refers to components in an SBOM but does not list the product's contents. CISA describes VEX as a form of security advisory.

What is the difference between VDR and VEX?

A VDR reports the vulnerabilities that affect a product's components and what to do about them, and can state how complete that knowledge is. A VEX states whether a particular vulnerability is actually exploitable in the product, with a status and justification.

Which BOM types are legally required?

As of October 2026, the requirements we found in primary texts are for SBOMs: FDA section 524B for cyber devices, the EU Cyber Resilience Act for products with digital elements on the EU market, and contract requirements that follow the CISA minimum elements. AI SBOM guidance exists but is guidance, not law.

How do I link an SBOM, a VEX and a CBOM for the same product?

In CycloneDX, give each document a unique serial number and a version, then reference the others with BOM-Link URNs in externalReferences (for example type exploitability-statement for a VEX and bom for another BOM). Use element links with a #bom-ref fragment when a VEX needs to name one exact component.

Should I produce one big BOM or many small ones?

Produce many small ones when owners, update rates or sensitivity differ, and link them. Merge into one file only when a single audience needs everything at once. The CycloneDX CLI supports both flat and hierarchical merges.

Fix it without waiting for upstream

A BOM, of any kind, only tells you which vulnerable component is in your product; someone still has to ship the build that removes it, and that is where most of the exposure lives. The fit is direct for the software members of the family (SBOM, OBOM images, AIBOM serving stacks) and indirect for hardware and cryptography, where the fix may come from a device vendor or a configuration change.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos generates an HBOM, CBOM or OBOM; they show the software inventory and remediation side.

This first demo is a real CLI session. You install the CLI, open the interactive terminal, ask it to fix a lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json, runs the install and tests with your approval, and pushes nothing. It ends with /scan ., which is the same scan that produces the software inventory an SBOM is built from.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code, and scans from the terminal. If your SBOMs have to be produced inside your own network, close to the build, this is the shape of that flow.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, you can ask questions about projects, components and vulnerabilities in plain language, which is a quick way to answer "which of our products contain this component?" from the inventories you already hold.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard or read the CLI documentation.

Quick check

Sources

• CycloneDX: Software Bill of Materials (SBOM) capability
• CycloneDX: SaaSBOM capability
• CycloneDX: Hardware Bill of Materials (HBOM) capability
• CycloneDX: Operations Bill of Materials (OBOM) capability
• CycloneDX: Manufacturing Bill of Materials (MBOM) capability
• CycloneDX: Machine Learning Bill of Materials (ML-BOM) capability
• CycloneDX: Cryptography Bill of Materials (CBOM) capability
• CycloneDX: Vulnerability Disclosure Report (VDR) capability
• CycloneDX: Vulnerability Exploitability eXchange (VEX) capability
• CycloneDX: Bill of Vulnerabilities (BOV) capability
• CycloneDX: Attestations (CDXA) capability
• CycloneDX: BOM-Link
• CycloneDX specification repository: bom-1.7.schema.json
• Ecma International: ECMA-424
• SPDX Specification 3.0.1
• SPDX 3.0.1: Conformance and profiles
• SPDX 3.0.1: SbomType vocabulary
• SPDX 3.0.1: AI profile
• SPDX 3.0.1: Dataset profile
• SPDX 3.0.1: Security profile
• CISA: Software Bill of Materials (SBOM)
• CISA: 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA: Types of Software Bill of Materials (SBOM)
• CISA: Software Bill of Materials for AI, Minimum Elements (listing)
• NTIA: The Minimum Elements For a Software Bill of Materials (2021)
• FDA: Cybersecurity in Medical Devices, Quality Management System Considerations and Content of Premarket Submissions (February 2026)
• EUR-Lex: Regulation (EU) 2024/2847, the Cyber Resilience Act
• OWASP GenAI Security Project: OWASP AIBOM
• OpenVEX specification
• cdxgen README (CycloneDX)
• CycloneDX CLI README

Last reviewed: 23 October 2026.