In this piece
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?
| Decision factor | CycloneDX | SPDX |
|---|---|---|
| Primary orientation | Product security and BOM operations | Provenance, licensing, and artifact relationships |
| AI representation | ML-BOM capability with model and dataset components | AI profile composed with software and other profiles |
| Team fit | Existing CycloneDX/SBOM and vulnerability pipeline | Existing SPDX, legal, research, or supply-chain graph pipeline |
| Stable targets | CycloneDX 1.7; schema distribution 1.7.2 | SPDX 3.0.1; check AI and Dataset profiles |
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.
- In CycloneDX 1.7, declare reusable datasets as data components and reference their bom-ref from the model card. In SPDX 3.0.1, represent them as DatasetPackage records and connect the AIPackage to each with trainedOn or testedOn as appropriate.
- 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.
- Pin the schema and validator versions in CI. A 1.7.2 CycloneDX schema release still uses specVersion 1.7 in the document. For SPDX, verify AI and Dataset profile conformance separately and test that the receiver preserves typed relationships and licenses.
- 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
- Select one deployed AI feature and enumerate every model, dataset, service, runtime, and software dependency.
- Define identifiers, relationship vocabulary, disclosure tiers, and ownership.
- Encode the same system in CycloneDX and SPDX, then score completeness, tooling, validation, and buyer fit.
- Choose one external format while keeping the internal record format-neutral.
- Generate, validate, sign, store, and attach the AIBOM to the release artifact.
- Run an upstream-model incident drill and measure time to identify affected deployments.
Secure the path from code to release
Need dependency, secret, build or release controls your team can operate? Define one repository and delivery path, then agree the controls, exception owner and evidence required before release.
Relevant service:
- Related delivery experience: Polity
Related application engineering experience. This case is not evidence of a security audit or of results from this service.
- Decide it first: Software QA checklist before launch
AI Bill of Materials FAQ
Is an AIBOM the same as an SBOM?
Does CycloneDX support machine-learning BOMs?
Does SPDX support AI artifacts?
Should customers receive the complete internal AIBOM?
Final thoughts
Choose the format your downstream users and controls can operate, but keep one authoritative internal graph. The success metric is not a valid JSON file. It is faster, more accurate impact analysis for a real deployed AI system.
Primary sources
- OWASP CycloneDX ML-BOM capability. Official model, dataset, service, and relationship coverage
- SPDX 3 profiles. Official overview of the AI profile and profile composition
- SPDX specifications. Current specification and model resources
- CycloneDX 1.7.2 release. Schema patch for the 1.7 specification
- OWASP AI/ML-BOM guide. Model-card and dataset representation
- SPDX 3.0.1 conformance. Independent compliance points for AI and Dataset profiles
- SPDX 3.0.1 relationship types. Direction and semantics of trainedOn and testedOn