AI SBOM crosswalk

The 50 G7 AI bill of materials minimum elements, mapped element by element against cyclonedx-1.7 and spdx-3.0.1. Data only. No conformance policy is expressed here.

cyclonedx-1.7: 23 direct, 23 partial, 4 properties only, 0 absent

spdx-3.0.1: 27 direct, 14 partial, 3 properties only, 6 absent

The source specification assigns no required, optional or recommended level to any element, and uses no RFC 2119 keywords. Every element here is marked 'unspecified'. Any conformance policy is the implementer's own and should be declared as such.

What the fits mean

direct: The format has a purpose-built field that carries this element.
partial: A field exists but is narrower, differently scoped, or uses an incompatible vocabulary.
properties-only: Expressible only through a free-form property bag or an external link. Not interoperable.
none: No representation at all.

Metadata

Element	cyclonedx-1.7	spdx-3.0.1
SBOM author Entity that generated the SBOM. Distinct from the producer of the thing described.	direct `metadata.authors[] (organizationalContact)` `metadata.manufacturer`	direct `CreationInfo.createdBy -> Agent`
SBOM version Version of the SBOM document itself, per component name/version pair. CDX version is an integer, not SemVer. SPDX 3.0.1 has no SBOM document version at all. Real gap in both.	partial `version (integer at BOM root)`	none
SBOM data format name Which format this SBOM is written in.	direct `bomFormat (const 'CycloneDX')`	direct `@context + type: SpdxDocument`
SBOM data format version Version of that format. Deprecated versions should not be used.	direct `specVersion (e.g. '1.7')`	direct `CreationInfo.specVersion (e.g. '3.0.1')`
SBOM author signature Digital signature of the SBOM author, for integrity and authenticity. THE COMMERCIAL HOOK. CycloneDX has a signature slot; SPDX 3.0.1 does not, so SPDX signing is out of band. Neither spec names a signature format (no Sigstore, DSSE, JWS or in-toto).	direct `signature (JSF, jsf-0.82 schema)` `also declarations[].signature and citation[].signature`	none
SBOM tool name Tool the author used to build the SBOM.	direct `metadata.tools.components[].name`	direct `CreationInfo.createdUsing[] -> Tool.name`
SBOM tool version Version of that tool. If none, say 'unknown'. Empty is non-conformant. Explicit 'unknown' is conformant. Neither format enforces this.	direct `metadata.tools.components[].version`	partial `Tool as Package -> packageVersion`
SBOM generation context Lifecycle phase at which the SBOM was made. Vocabularies do not line up with each other or with the spec's three example values. SPDX scopes relationships, not the document.	partial `metadata.lifecycles[].phase (design, pre-build, build, post-build, operations, discovery, decommission)`	partial `LifecycleScopeType on relationships (design, build, development, test, runtime, other)`
SBOM timestamp When the SBOM data was last changed. Every version gets a new one. RFC 9557 permits suffixes such as [America/Chicago] that RFC 3339 validators reject. Both formats validate as plain date-time, so a strictly conformant timestamp can fail their schemas.	partial `metadata.timestamp (JSON Schema format: date-time)`	partial `CreationInfo.created (xsd:dateTimeStamp)`
SBOM dependency relationship Component X includes Y; or Y is derived from or a descendant of Z.	direct `dependencies[] (ref, dependsOn, provides)` `pedigree.ancestors/descendants/variants for derivation`	direct `Relationship: contains, dependsOn, ancestorOf, descendantOf, hasVariant`

System Level Properties

Element	cyclonedx-1.7	spdx-3.0.1
System name Human-readable name of the whole AI system. Neither format allows alternate names on a single component. Spec explicitly asks for multiple entries. Use properties or externalIdentifier as a workaround.	partial `metadata.component.name`	partial `Package.name`
System components Everything included in the AI system: models, databases, tools.	direct `metadata.component.components[]` `components[] + dependencies[]`	direct `Relationship contains`
System producer Entity that creates, defines and identifies the system.	direct `metadata.component.manufacturer / .supplier`	direct `Artifact.originatedBy / suppliedBy`
System version Version of the system. If none, say 'unknown'.	direct `metadata.component.version`	direct `Package.packageVersion`
System timestamp Last update to the system, including model or software updates. SPDX is materially better here. CycloneDX has no component-level 'last updated' field.	partial	direct `Artifact.builtTime / releaseTime / validUntilTime`
System data flow Data movement between components: endpoints, APIs, agent protocols, external services. CycloneDX SaaSBOM services model this properly. SPDX 3.0.1 cannot express data flow at all. Biggest single divergence between the two formats.	direct `services[].endpoints[]` `services[].data[] with flow (inbound, outbound, bi-directional, unknown) and classification`	none
System data usage How data is processed and consumed, including logging and derived metadata. Both weak. No structured notion of 'is user input used for training'.	partial `services[].data[].classification` `externalReferences[]`	partial `AIPackage.informationAboutApplication (free text)`
System input/output properties Input and output types, modality, preprocessing, tokenizer. CycloneDX allows exactly ONE key here (format) because inputOutputMLParameters is additionalProperties:false. Modality lives in the separate cdx:ai-ml property taxonomy, not the schema. This is model-level in CDX, not system-level.	partial `modelCard.modelParameters.inputs[].format / outputs[].format`	partial `AIPackage.informationAboutApplication (free text)`
Intended application area Domain the system is deployed in: healthcare, finance, cybersecurity, real time. SPDX has a purpose-built field. CycloneDX only has model-level use cases.	partial `modelCard.considerations.useCases[]`	direct `AIPackage.domain (0..*)`

Models

Element	cyclonedx-1.7	spdx-3.0.1
Model name Human-readable model name. Same alternate-names gap as System name.	partial `components[].name (type: machine-learning-model)`	partial `AIPackage.name`
Model identifier One or more machine-readable identifiers. Both support the named schemes. Hugging Face PURL type (pkg:huggingface/...) is the de facto model identifier.	direct `components[].purl, .cpe, .swid, .omniborId, .swhid, .bom-ref`	direct `Element.spdxId` `Element.externalIdentifier[]` `Package.packageUrl`
Model version Model version. If none, say 'unknown'.	direct `components[].version`	direct `Package.packageVersion`
Model timestamp Last update to the model, or its production release date. SPDX better.	partial `components[].releaseNotes.timestamp`	direct `Artifact.releaseTime / builtTime`
Model producer Who pre-trained, post-trained or fine-tuned the model. Also the security point of contact.	direct `components[].manufacturer, .supplier, .authors[], .publisher`	direct `Artifact.originatedBy (0..*), suppliedBy (0..1)`
Model description Capabilities, known limitations, and lineage including the predecessor model. LINEAGE IS THE PROBLEM. CycloneDX pedigree is structured but generic. SPDX 3.0.1 has no base-model edge at all, and even 3.1-dev's finetunedOn points at a dataset, not a parent model. 'This was fine-tuned from Llama 3' has no interoperable representation in either format.	partial `components[].description` `modelCard.considerations.technicalLimitations[]` `pedigree.ancestors[]`	partial `Element.description` `AIPackage.limitation` `AIPackage.informationAboutTraining` `ancestorOf relationship`
Model hash value Hash of the weights or model file.	direct `components[].hashes[].content`	direct `Element.verifiedUsing -> Hash.hashValue`
Model hash algorithm Algorithm that produced the hash. NEITHER FORMAT USES IANA NAMES. Both have their own closed enums. A conformance checker has to map IANA names onto each format's vocabulary, and the sets do not fully overlap.	partial `components[].hashes[].alg (closed enum: MD5, SHA-1, SHA-256/384/512, SHA3-, BLAKE2b-, BLAKE3)`	partial `Hash.algorithm (SPDX HashAlgorithm vocabulary)`
Model properties Architecture, parameter count, network type, hyperparameters. Explicitly nestable. CycloneDX is richer via the property taxonomy but the taxonomy sits outside the schema. SPDX hyperparameters are untyped strings with no units.	direct `modelCard.modelParameters.approach.type (enum: supervised, unsupervised, reinforcement-learning, semi-supervised, self-supervised), .task, .architectureFamily, .modelArchitecture` `plus cdx:ai-ml:model:parameter:count and :hyperparameter:* taxonomy`	direct `AIPackage.typeOfModel (0..*)` `AIPackage.hyperparameter[] (DictionaryEntry key/value strings)`
Model input-output properties Input and output types, context length, modality, tokenizer. Context length and modality have no schema home in either format. CycloneDX puts modality in the taxonomy (cdx:ai-ml:model:modality); context length only as a hyperparameter property.	partial `modelCard.modelParameters.inputs[].format / outputs[].format only`	none
Model training properties All training: pre-training, fine-tuning, continual learning, RLHF, DPO, PPO, GRPO. CycloneDX formulation can model the actual training run as a workflow. SPDX models it as a Build. Both are possible, neither is conventional, and no two producers will do it the same way.	partial `modelCard.modelParameters.approach.type` `formulation[].workflows[] for the training run` `cdx:ai-ml:model:parameter:tune_method (full, sft, rlhf, adapter, prompt, lora, alora, qlora)`	partial `AIPackage.informationAboutTraining (free text)` `trainedOn relationship`
Model license Licence type, and whether open weight, open architecture, open data or open training. OPEN-WEIGHT VOCABULARY IS MISSING EVERYWHERE. Neither format has any way to say open weight vs open architecture vs open data vs open training. This is a named requirement with no representation.	partial `components[].licenses[] (SPDX expression)`	partial `hasDeclaredLicense and hasConcludedLicense relationships (exactly one of each REQUIRED on an AIPackage)`
Model external references Links to model cards, system cards, papers, documentation. CycloneDX has a dedicated model-card reference type. SPDX external refs are less typed.	direct `components[].externalReferences[] (47-value type enum incl. model-card, documentation, attestation, threat-model, adversary-model, risk-assessment, certification-report, pentest-report)`	direct `Element.externalRef[]`

Datasets Properties

Element	cyclonedx-1.7	spdx-3.0.1
Dataset name Name given by the dataset creator.	direct `componentData.name` `or components[].name with type: data`	direct `DatasetPackage.name`
Dataset description What the dataset is for: pre-training, fine-tuning, benchmark, evaluation. Public or private.	direct `componentData.description`	direct `Element.description` `DatasetPackage.intendedUse`
Dataset content What is in it and in what shape: financial, medical, image, audio, JSON, XML. SPDX is clearly better. Its 14-value datasetType is the only real content vocabulary in either format, and it is the ONLY required property in the whole SPDX AI/Dataset surface (minCount 1).	partial `componentData.type (enum: source-code, configuration, dataset, definition, other)` `.contents.{attachment,url,properties}`	direct `DatasetPackage.datasetType (14-value enum: audio, categorical, graph, image, noAssertion, numeric, other, sensor, structured, syntactic, text, timeseries, timestamp, video)` `.datasetSize (bytes)`
Dataset identifier Unique identification of the dataset.	direct `componentData.bom-ref` `components[].purl`	direct `Element.spdxId` `externalIdentifier[]` `Package.downloadLocation`
Dataset hash Hash over the dataset file. TRAP: CycloneDX componentData has NO hash property of its own. You can only hash the wrapping component. Also note the spec itself omits a Dataset hash algorithm element, which is an asymmetry with the Models cluster.	partial `components[].hashes[] on the wrapping component only`	direct `Element.verifiedUsing -> Hash`
Dataset provenance Origin, collection method (web crawl, commercial agreement), post-processing, curation, labelling, creator, synthetic-data method. SPDX has purpose-built fields for collection and preprocessing. CycloneDX has stewardship roles SPDX lacks. Neither has a synthetic-data-method field.	partial `componentData.governance.{custodians,stewards,owners}` `.contents.url` `formulation[] for the pipeline`	direct `DatasetPackage.dataCollectionProcess` `.dataPreprocessing (0..*)` `.anonymizationMethodUsed` `Artifact.originatedBy`
Dataset statistical properties Mean, variance, median, mode, range, skewness across the dataset lifecycle. REAL GAP IN BOTH. No statistical characterisation exists anywhere in either format. Nearest is SPDX datasetNoise (free text) and CycloneDX graphics (base64 images).	properties-only `componentData.properties[] or .graphics`	none
Dataset sensitivity Whether it contains PII, freely accessible, copyright-protected, sensitive (financial, medical) or national-security data. SPDX has controlled vocabularies, CycloneDX has none. But NEITHER covers copyright-protected or national-security categories, which the spec names explicitly. SPDX 3.1-dev adds amberStrict.	partial `componentData.sensitiveData[] (free-text array)` `.classification (unconstrained string)`	partial `DatasetPackage.hasSensitivePersonalInformation (PresenceType: yes/no/noAssertion)` `.confidentialityLevel (TLP: red, amber, green, clear)`
Dataset dependency relationship Software used to create, modify and maintain the dataset. Derivation from another dataset. Both express it, neither conventionally.	partial `dependencies[] on the data component` `formulation[].components[] for the tooling`	partial `Relationship: dependsOn, usesTool, ancestorOf` `Build profile for the pipeline`
Dataset license Licence type of the dataset.	direct `components[].licenses[]`	direct `hasDeclaredLicense and hasConcludedLicense (exactly one each REQUIRED on a DatasetPackage)`

Infrastructure

Element	cyclonedx-1.7	spdx-3.0.1
Infrastructure software Firmware, package managers, third-party libraries, frameworks, runtimes, tools needed to run the system.	direct `components[] of type library/framework/container/operating-system + dependencies[]` `formulation[].components[]`	direct `Relationship dependsOn / usesTool` `Build profile`
Infrastructure hardware Link to an existing HBOM covering the hardware the system runs on. SPDX 3.0.1 cannot express hardware at all. CycloneDX can link a separate BOM but has no HBOM profile either. Note OMB M-26-05 now makes agencies inventory hardware as well as software, so this gap has a buyer.	partial `externalReferences[].type: 'bom' with a BOM-Link URN` `components[].type: 'device'`	none

Security Properties

Element	cyclonedx-1.7	spdx-3.0.1
Security controls General controls (encryption, data minimisation, differential privacy, access control, API auth, anomaly detection) AND AI-specific controls (adversarial robustness training, prompt injection controls, I/O filters, training-data curation). THE BIGGEST GAP ON THIS SHEET. Neither format has ANY field for adversarial robustness, prompt injection resistance, jailbreak resistance, data poisoning, watermarking, guardrails or red-teaming. Zero hits for all of those terms in both schemas. This is unclaimed territory.	properties-only `properties[] under a private namespace` `externalReferences[].type: threat-model / adversary-model / risk-assessment` `declarations[] (CDXA) against definitions.standards[]`	properties-only `Extension profile` `AIPackage.standardCompliance (partial)`
Security compliance Certification schemes, standards or frameworks the model or system complies with. SPDX has a plain field. CycloneDX requires the heavier Attestations construct.	partial `declarations[] (CDXA)` `externalReferences[].type: certification-report`	direct `AIPackage.standardCompliance (xsd:string, 0..*)`
Cybersecurity policy information Link to the producer's published security.txt. Neither has a security.txt reference type by name. Nearest fit only.	partial `externalReferences[] with an appropriate type`	partial `Element.externalRef[] (securityAdvisory, securityOther)`
Vulnerability referencing Link to databases or repositories showing exploitability of known vulnerabilities. Both strong, but both are CVE-shaped. Neither can express a model-level attack surface, only vulnerabilities in software dependencies.	direct `vulnerabilities[] (CVE, CWE, CVSS ratings, VEX analysis state)` `externalReferences[].type: vulnerability-assertion`	direct `Security profile: Vulnerability, VulnAssessmentRelationship, VEX relationships, CVSS v2/v3/v4, EPSS, SSVC`

Key Performance Indicators

Element	cyclonedx-1.7	spdx-3.0.1
Security metrics Metrics for the security characteristics of the models or the system, such as robustness benchmarks. Untyped in both. No units, no thresholds beyond SPDX metricDecisionThreshold, no security semantics. And in CycloneDX there is NO field linking a metric to the dataset it was measured on.	properties-only `modelCard.quantitativeAnalysis.performanceMetrics[] (type free text, value is a STRING, optional slice and confidence interval)`	properties-only `AIPackage.metric[] (DictionaryEntry: string key, string value)`
Operational performance KPIs Uptime, incident resolution time, latency, request throughput, load balancing. REAL GAP IN BOTH. No operational-telemetry concept exists in either format. This is arguably out of scope for a static BOM, and worth saying so.	properties-only `properties[] only`	properties-only `AIPackage.metric[] only`

Take it

Version 0.1.0, compiled 2026-08-29, released under CC BY 4.0. The machine readable copies live at docs/crosswalk/data/ as JSON and CSV, with the method in docs/crosswalk/METHODOLOGY.md. Corrections are the point: if a mapping here is wrong, the file to change is in the repository and the change is visible in its history.