AI Bill of Materials: CycloneDX vs SPDX Implementation Guide

An AI Bill of Materials is a machine-readable inventory of the software, models, datasets, services, licenses, provenance, and relationships that make an AI system. Choose CycloneDX when product-security and operational SBOM workflows are primary. Choose SPDX when detailed provenance, licensing, and graph relationships across AI and software artifacts are primary. Both can work if one internal inventory is authoritative.

An AIBOM is evidence infrastructure, not a compliance badge. It should answer which model and dataset affected a release, where they came from, what terms apply, which evaluations passed, and which deployed systems need action when an upstream component changes.

CycloneDX or SPDX?

What should an AIBOM record?

Inventory stable identifiers and versions first, then add provenance and policy. Include the base model, adapters, prompts or policy packages when they alter behavior, training and evaluation datasets, serving runtime, retrieval indexes, external APIs, licenses, hashes, suppliers, evaluations, and deployment relationships.

• Identify artifacts with immutable hashes or registry digests, not display names such as latest.
• Distinguish trained-on, fine-tuned-with, evaluated-on, retrieved-from, and served-by relationships.
• Store sensitive dataset details in access-controlled evidence and expose only safe references in distributable BOMs.
• Link every production deployment to the exact AIBOM revision used for its release.

How do you choose without locking in?

Define a format-neutral internal schema for identity, provenance, relationship, license, evaluation, and deployment. Generate the external standard from that source. This prevents two inventories from drifting and makes a future customer requirement a mapping exercise rather than a rebuild.

• Prototype the hardest artifact, usually a fine-tuned model with several datasets and a hosted inference dependency.
• Validate generated documents with official schemas and stable example fixtures.
• Round-trip one release and compare whether any decision-critical fields disappear.

Where should AIBOM generation run?

Generate and sign it in the release pipeline after artifacts are immutable but before deployment approval. Enrich it from model registries, dataset catalogs, dependency scanners, evaluation results, and infrastructure manifests. Runtime discovery should detect drift, not replace declared build provenance.

• Fail the release for missing identity, prohibited licenses, unapproved models, or absent evaluations.
• Publish an access-appropriate customer version and retain a richer internal evidence version.
• Trigger impact analysis when a vulnerability, license, supplier, or model advisory changes.

A two-sprint AIBOM pilot

1. Select one deployed AI feature and enumerate every model, dataset, service, runtime, and software dependency.
2. Define identifiers, relationship vocabulary, disclosure tiers, and ownership.
3. Encode the same system in CycloneDX and SPDX, then score completeness, tooling, validation, and buyer fit.
4. Choose one external format while keeping the internal record format-neutral.
5. Generate, validate, sign, store, and attach the AIBOM to the release artifact.
6. Run an upstream-model incident drill and measure time to identify affected deployments.

Primary sources

1. OWASP CycloneDX ML-BOM capability. Official model, dataset, service, and relationship coverage
2. SPDX 3 profiles. Official overview of the AI profile and profile composition
3. SPDX specifications. Current specification and model resources