1. Purpose and Context of Use

Enterprise open source governance programs have already reached the stage of mandating that suppliers submit a Software Bill of Materials (SBOM) and of operating concrete submission requirements. AI systems need the same transparency requirement extended to models and datasets, but existing SBOM requirements cover only software components and cannot capture AI-specific information. This report defines, using international standards and regulatory grounds, which fields a bill of materials for AI (hereafter AI BOM) should require and which it should treat as optional.

A note on why AI BOM is used as the umbrella term here. Three of the sources compared below call the same thing by different names. The G7 Cybersecurity Working Group, whose element list this report draws on, calls it SBOM for AI; the OpenChain project calls it AI SBOM; CycloneDX calls it a Machine Learning Bill of Materials (ML-BOM). Of the remaining two, SPDX expresses it as an AI profile rather than a separate abbreviation, and the NTIA minimum elements predate AI and cover the general SBOM. Elevating any one of these to represent the rest would misname the others, so what follows uses AI BOM for the general concept and reproduces each standard’s own term only when referring to that standard specifically.

The fields assessed here are the 50 elements of “SBOM for AI — Minimum Elements,” published by the G7 Cybersecurity Working Group. Using these 50 as rows, this report compares the requirement strength of five authoritative standards to sort each element into required or optional.

The same matrix is applied differently across three enterprise usage contexts.

• Production: the fields an in-house AI model development team must fill in when authoring an AI BOM directly.
• Ingestion: the fields that must be checked to assess transparency and risk when bringing in and using an external model or dataset.
• Supplier requirements: the fields to require submission of from suppliers that provide AI models to the organization.

Figure 1. How the boundary of required shifts by role for the same matrix(compiled from research)

2. Methodology

2.1 Sources Used for Consensus Tallying

Whether each field is required is determined by summing the requirement strength of the following five sources.

• G7 “SBOM for AI — Minimum Elements” (G7, jointly led by the BSI and the ACN, 2026): recommends all 50 elements as “minimum elements.” Because it does not distinguish required from optional at the element level, this matrix credits G7 with one vote of “designated as a minimum element” for every element.
• SPDX 3.0.1: the specification directly defines the cardinality (whether required) of each property in the AI Profile’sAIPackage, the Dataset Profile’sDatasetPackage, and the common classes in Core.
• CycloneDX 1.6: required fields are defined by therequired array in the JSON schema.
• NTIA “The Minimum Elements For a Software Bill of Materials (SBOM)” (2021): defines the seven baseline data fields for a general software SBOM.
• OpenChain AI Compliance Management Guide (Version 1, 2025): a process standard that does not define data fields, but whose license obligation procedures mandate identifying and documenting model and dataset licenses.

2.2 Determination Rule

A field is determined required if two or more sources require the field’s existence itself, and optional otherwise. Since G7 gives one vote to every element, the determination in practice comes down to whether at least one other source requires the field’s existence.

Requiring existence here means class-level required cardinality (the required properties of SPDX’sAIPackage/DatasetPackage), document-root requirements (CycloneDX’sbomFormat/specVersion), the seven NTIA baseline fields, and OpenChain’s shall-level process. Conditional requirements enforced only when an object is created — for example, the algorithm and value inside a hash object, or the name inside a component object — are not requirements to include the object itself, so they were not counted as existence requirements. However, these conditional requirements and items of high integrity or security value were left optional while being marked recommended in the role-based application.

Figure 2. The consensus determination rule and G7’s role in it(compiled from research)

Applying this rule yields 20 required and 30 optional elements out of the 50.

2.3 Marking Regulatory Basis

Whether a binding regulation applies to a given field is marked on a separate axis, not folded into the consensus tally, because no regulation mandates an AI BOM under that name. The Cyber Resilience Act (CRA) requires a general software SBOM; the AI Act, U.S. Food and Drug Administration (FDA) guidance, and domestic regimes require documentation obligations.Direct marks a case where the regulation explicitly requires that item;Indirect marks a case where the item is not itself an SBOM requirement but a documentation or vulnerability-handling obligation effectively requires the same information.

3. Overview of the Consensus Results

The distribution of required and optional elements by cluster is as follows.

Figure 3. Required/optional distribution by cluster(compiled from research)

The 20 elements determined required are all foundational to identification and traceability: who made it (author, producer), what it is (name, identifier, version), when it was made (timestamp), what it is composed of (components, dependency relationships, dataset content), and what license applies (model and dataset licenses). Two or more standards consistently require the existence of this information.

By contrast, detailed model attributes (architecture, training technique, input/output characteristics), dataset statistics and sensitivity, security controls, and key performance indicators fall to optional because only G7 lists them as minimum elements and no other standard mandates their existence. These items are optional by consensus, but because they are used directly for transparency and risk assessment in the ingestion and supplier-requirement contexts, they are raised again in the role-based application.

One structural point is worth noting. The required determination in the AI-specific clusters (Model, Dataset) is effectively driven by G7 and SPDX 3.0. NTIA, being a general software SBOM standard, contributes only to metadata and the identification lineage; OpenChain defines no fields beyond licensing; and CycloneDX makes everything but its two root fields conditionally required. SPDX 3.0’s AI and Dataset profiles are, in effect, still the only field-level standard for AI BOM with any real density.

4. Field Matrix

The notation conventions are as follows. The source columns useRequired (existence required),Conditional (enforced only when the object is created),Approximate (no dedicated field; handled through a relationship or a general property instead),Optional, and– (no equivalent). OpenChain’sRequired (P) denotes process enforcement rather than a data field. The role columns useRequired,Recommended,Optional, and–; given table width, the Production, Ingestion, and Supplier role columns are broken out into the §4.6 role-based application summary table.

4.1 Metadata Cluster

4.2 System-Level Attributes Cluster

4.3 Model Cluster

4.4 Dataset Attributes Cluster

4.5 Infrastructure, Security, and Key Performance Indicator Cluster

The Security cluster is entirely optional by consensus, but Vulnerability References and Cybersecurity Policy Information are items the CRA and FDA require directly. The consensus tally looks only at how standards define data fields, while regulation mandates the same information. For that reason, these two items are raised to required or recommended in the ingestion and supplier contexts. This is the representative case where the regulatory-basis marking adjusts the role-based application.

4.6 Role-Based Application Summary

This table gathers, for all 50 elements, the result of applying the §4.1–4.5 consensus determinations to the three contexts of production, ingestion, and supplier requirements. The role columns useRequired,Recommended,Optional, and–.

5. Role-Based Application in Detail

5.1 Production Perspective

When an in-house development team builds the model, information access is at its best, so the requirement level is set highest here. The 20 consensus-required elements remain required as is. In addition, items that are optional by consensus — detailed model and dataset attributes, hashes, training information — are set to recommended at production time, because if the producer does not record this information, no one downstream, whether an adopter or the rest of the supply chain, can ever recover it.

5.2 Ingestion Perspective

When bringing in an external model or dataset, fields that are used directly for transparency and risk assessment take priority. In addition to identification information (name, identifier, version, producer), Model Description, model and dataset licenses, Dataset Provenance, Dataset Sensitivity, and Vulnerability References are treated as required. Licenses are the basis for judging compliance risk; provenance and sensitivity for judging data legality and privacy risk; vulnerability references for judging security risk. These are optional by consensus but are core to ingestion review, so they are raised to required.

5.3 Supplier Requirement Perspective

The scope required from suppliers takes the 20 consensus-required elements as the baseline, considering what is realistically enforceable through contract. Model and dataset licenses, Dataset Provenance and Sensitivity, and Vulnerability References are added as required on top of that. This extends to models and data the same structure that existing software SBOM supplier requirements already enforce for identification, dependencies, and format compliance.

6. Limitations and Items Requiring Verification

The consensus determinations in this matrix rest on the cardinality defined in the standard specifications and on minimum-element provisions, with the regulatory-basis marking as a separate axis. The following items had limited access to primary sources and require separate verification.

The primary NTIA minimum elements specification (ntia.gov) blocks automated retrieval, so the seven baseline fields were reconfirmed against a public mirror. The primary text of the CRA Annex I, the AI Act annexes, and the FDA guidance (EUR-Lex, fda.gov) also had rendering and access-blocking issues and were cross-checked using mirrors and search aggregation. The training-data obligations in Korea’s Basic Act on AI could not be matched against the primary text down to the article and paragraph level, so they are marked “indirect (article unspecified).” These items will be reconfirmed against primary sources at a follow-up verification stage.

The field cardinality of SPDX 3.0 and CycloneDX 1.6 was confirmed directly from the specification’s class definitions and the original JSON schema, so confidence in these is high.

References

The main primary sources are as follows.

A1. G7 Cybersecurity Working Group (2026).Software Bill of Materials for AI — Minimum Elements. Jointly led by the BSI and the ACN, and jointly published with the other G7 cybersecurity agencies and the European Commission. —Used for: the 50-element row structure.

A2. SPDX Project (2024).System Package Data Exchange (SPDX) Specification, Version 3.0.1 — AI Profile, Dataset Profile, Core.https://spdx.github.io/spdx-spec/v3.0.1/ —Used for: model and dataset field cardinality.

A3. OWASP / ECMA International (2024).CycloneDX Bill of Materials Specification 1.6 (ECMA-424), JSON schema.https://cyclonedx.org/docs/1.6/json/ —Used for: determining required fields in the schema.

A4. NTIA, U.S. Department of Commerce (2021).The Minimum Elements For a Software Bill of Materials (SBOM).https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom —Used for: general SBOM minimum elements.

A5. OpenChain Project AI Work Group (2025).Artificial Intelligence System Bill of Materials — Compliance Management Guide, Version 1. —Used for: license obligation process.

A6. European Parliament and Council (2024).Regulation (EU) 2024/2847 — Cyber Resilience Act, Annex I. —Used for: SBOM and vulnerability-handling regulatory basis.

A7. European Parliament and Council (2024).Regulation (EU) 2024/1689 — AI Act, Article 53, Annex IV, XI, XII. —Used for: documentation and transparency regulatory basis.

A8. U.S. FDA (2023).Cybersecurity in Medical Devices: Premarket Submissions; FD&C Act §524B. —Used for: medical device SBOM regulatory basis.

A9. Ministry of Science and ICT, National Intelligence Service, and KISA (2026).Software Supply Chain Security Enhancement Roadmap for an Era of Everyday AI;Basic Act on the Development of Artificial Intelligence and the Establishment of Trust, etc. —Used for: domestic regulatory basis.

8. Structure of This Series

This article is the starting point of a five-part series. It carries the matrix above into operational documents for the three usage contexts, together with the toolset strategy that supports them.

• Supplier AI BOM Submission Requirements — the fields to require from suppliers and the submission protocol
• In-House Development Team AI BOM Authoring Guide — the required and recommended items an in-house production team must fill in
• External Model and Dataset Ingestion Checklist — risk review when bringing in external models and datasets
• AI BOM Toolset Design Strategy — the strategy for codifying the matrix as policy and integrating it with existing tools

Based on a survey of seven tool categories through their official repositories and documentation, this document lays out what to reuse from existing tools, what to extend or build new, in what order to build it, and what policy schema should define the matrix. The acquisition strategy was not fixed in advance but determined from the survey results, and the premise is that the organization already operates an existing SBOM platform (Dependency-Track).

1. Three Core Judgments

The standard path for generation, verification, storage, and model scanning already works with open source software. Theaibom command in cdxgen actually produces CycloneDX 1.6 AI BOMs, sbomqs and OPA check field conformance, Dependency-Track ingests the software layer, and ModelScan and sigstore model-signing reinforce model integrity. There is no need to build everything from scratch in-house.

Standardizing the format on CycloneDX 1.6 is the more realistic choice. The SPDX 3.0 AI Profile has richer expressive power, but no mature tool actually generates it, and Dependency-Track cannot ingest SPDX. SPDX 3.0 is kept as a standard to track, while CycloneDX is set as the primary operational format.

Where new construction is unavoidable is narrow and clear: the policy layer that checks AI-specific fields, an inventory that treats models and datasets as first-class objects, and the determination of license usage restrictions. Everything else is covered by reuse or extension.

2. Reuse Determinations by Area

In summary, of the thirteen areas, seven are reuse, three are extension, and three are new. The three new areas — AI- and role-specific conformance rules, the model/data inventory, and license usage-restriction determination — are where this project’s unique value is concentrated.

3. Build Priority

P0 — A Minimal Working Pipeline (Reuse-Focused)

The first step is to wire together off-the-shelf tools into an end-to-end pipeline. Generation produces CycloneDX 1.6 with cdxgenaibom, model files are scanned with ModelScan and signed with sigstore, and the results are uploaded to Dependency-Track to obtain software-layer vulnerabilities and impact analysis. Validation checks the presence of required fields with an sbomqs custom policy. Almost all of this stage is reuse, so it delivers value quickly.

P1 — Extending the AI-Specific Layer

The next step adds new value. Codify the matrix into a policy schema to implement role-specific conformance checking (Section 4), and carry models and datasets through CycloneDXproperties or external references to secure inventory traceability. Augment the license pipeline with an AI license dictionary (RAIL, OpenRAIL, Llama, Gemma, OpenMDW, CDLA), and receive model risk as huntr CVEs relayed through NVD.

P2 — New and Research Areas

Last are the parts where standards and research still need to mature. Automatic extraction of deep fields such as dataset statistics or bias, automatic determination of license usage restrictions, and data poisoning are handled through provenance and integrity traceability instead of detection. Bring SPDX 3.0 generation on board once the tool ecosystem matures, but for now keep it only as a standard to track. When Dependency-Track’s support for model/data classifiers (issue #4361) lands, promote P1’s workaround to a first-class inventory.

4. Policy Schema Design

Defining the matrix’s “element x required/optional x role” as a machine-readable policy is the core of this toolset. Since the survey found no tool that treats role-specific required sets as a first-class concept, this must be designed directly. It is split into two layers.

4.1 Field Registry

A table mapping each of the G7’s 50 elements to a CycloneDX path (and, eventually, an SPDX path) is kept in one place. TheAI BOM Field Requirements Matrix already contains an element-by-element source mapping, so moving it into a machine-readable form looks like this.

# field-registry.yaml — maps G7 elements to BOM pathsmodel_license:g7:Model licensecyclonedx:"components[?type=='machine-learning-model'].licenses"spdx:"Relationship(hasDeclaredLicense) from AIPackage"dataset_provenance:g7:Dataset provenancecyclonedx:"components[?type=='data'].data[].governance"spdx:"DatasetPackage.originatedBy / dataCollectionProcess"vulnerability_referencing:g7:Vulnerability referencingcyclonedx:"vulnerabilities[] or externalReferences[?type=='vcs']"spdx:"VulnAssessmentRelationship"

4.2 Role-Specific Policy Files

The required set for each of production, ingestion, and supplier is kept as a separate policy file. This simply carries over the role column of the matrix.

# policy/supplier.yaml — required elements for supplier submission (Section 4.6, 20 supplier-required elements)required:-sbom_author-sbom_data_format_name-sbom_data_format_version-sbom_timestamp-sbom_dependency_relationship-system_name-system_components-system_producer-system_version-model_name-model_identifier-model_version-model_producer-model_license-dataset_name-dataset_identifier-dataset_provenance-dataset_sensitivity-dataset_license-vulnerability_referencingrecommended:-model_timestamp-dataset_content-model_hash_value

4.3 Determination Engine

Two engines are recommended together. For a quick start, an sbomqs custom policy (YAML) puts the role-specific files into operation today with no engine to learn, converting the fulfillment rate into a score. Where expressiveness is needed, OPA/Rego (conftest) branches on the input BOM’s role value to determine the required set. Because Rego follows the field registry’s paths to evaluate presence, it can express conditional requirements and cross-field consistency as well.

# policy/aibom.rego — skeleton for role-specific required-field checkingpackageaibomdeny[msg]{role:=input.metadata.properties[_].value# e.g. "supplier"req:=data.policy[role].required[_]notfield_present(req)msg:=sprintf("Required element missing: %s (role: %s)",[req,role])}

OSCAL is a tool built for expressing security controls, which makes it more than SBOM fields need, and it does not execute validation on its own, so it is not adopted. It is worth considering only if there arises a need to produce upper-level artifacts for regulatory or audit purposes (a requirements catalog, an assessment result report) in a federal-friendly format.

5. Reference Architecture and Dependency-Track Integration

The BOM for an AI system splits into a software dependency layer and a model/dataset layer. Dependency-Track handles the former layer right now, and does not yet accept the latter as a first-class citizen (issue #4361 is open as of this research and may change later). Integration is therefore split by layer.

Figure 4. The common pipeline and the two layers it splits into after validation(compiled from the survey)

The software layer needs almost no extra work. cdxgen turns an ML project’s PyPI or npm dependencies into CycloneDX, which is uploaded to Dependency-Track, correlating vulnerabilities against OSV and NVD and even providing impact analysis for “which projects use this component?” CVEs that huntr issued for ML libraries are also caught, passing through NVD.

The model/dataset layer is routed around until classifier support arrives. In the short term, models and datasets are uploaded as generic components, while core model card fields are carried through CycloneDXproperties or external references to preserve them. Discoverability is limited, but traceability is preserved. Threats unique to model files (unsafe pickle, backdoored weights) don’t fit the CVE matching model, so they are checked separately with ModelScan and the results are linked to policy or tickets.

6. Limitations and Items Requiring Verification

The tool facts in this strategy were confirmed against each project’s official repository and documentation. The following require reconfirmation before adoption.

The licensing area carries the risk of a mismatch between what is declared and what is actually true. The so-called permissive-washing risk, in which the license declared on a platform diverges from the actual component license of the model or dataset, is well known, and it compounds an existing limitation: existing software license tools cannot parse model cards or dataset cards, or trace training data provenance. This toolset does not promise automatic detection for this and leaves verifying the match between declared license and actual output as a new-build target.

The timing of Dependency-Track’s support for model/data classifiers (#4361) is an external schedule outside our control. Because P1’s model/data inventory depends on this schedule, it should be designed with the workaround (preservingproperties) as the default, promoting to first-class inventory once classifier support lands.

GUAC’s AI-specific handling, OSV’s model-specific record scheme, and any connector letting Dependency-Track directly consume huntr Insights and ModelScan results are all confirmed absent or unverifiable. No standard yet links model risk feeds and SBOM inventories, so this connection has to be filled with custom glue code.

There is no production tool for data poisoning detection. This toolset does not promise automatic poisoning detection and limits itself to traceability and preventive controls that record data provenance, hashes, and whether verification passed.

7. References

The tool determinations in this article were confirmed against each project’s official repository and documentation as primary sources. All access dates are 2026-06.

A1. CycloneDX / cdxgen Project.cdxgen — AI/ML BOM generation and theaibom CLI,--spec-version.https://github.com/CycloneDX/cdxgen (accessed 2026-06). —Used for: basis that cdxgen’saibom automatically generates CycloneDX 1.6 AI BOMs.

A2. CycloneDX.Machine Learning Bill of Materials (ML-BOM) Capability Overview.https://cyclonedx.org/capabilities/mlbom/ (accessed 2026-06). —Used for: standard basis that CycloneDX 1.6 definesmachine-learning-model and modelCard.

A3. SPDX.SPDX 3.0.1 — AI Profile Specification.https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/ (accessed 2026-06). —Used for: basis that the SPDX 3.0 AI Profile exists at the specification level (expressiveness comparison).

A4. SPDX.tools-python (spdx-tools) — 3.0 experimental write-only, not recommended for production.https://github.com/spdx/tools-python (accessed 2026-06). —Used for: basis that no mature tool exists to generate the SPDX 3.0 AI Profile.

A5. interlynk-io.sbomqs — Policy Guide (custom policy, required type, feature scoring).https://github.com/interlynk-io/sbomqs/blob/main/docs/guides/policy.md (accessed 2026-06). —Used for: basis that sbomqs enforces field presence via custom policy and converts it into a conformance score.

A6. Open Policy Agent.Conftest — OPA/Rego policy evaluation for configuration files.https://github.com/open-policy-agent/conftest (accessed 2026-06). —Used for: basis that CycloneDX/SPDX JSON can be evaluated with Rego to branch role-specific required sets.

A7. OWASP Dependency-Track.Policy Compliance Documentation (condition types, regex values).https://docs.dependencytrack.org/usage/policy-compliance/ (accessed 2026-06). —Used for: basis that the Dependency-Track policy engine centers on license, vulnerability, and component coordinates, with policies configurable per project/tag.

A8. DependencyTrack.Issue #4361 — Request to support CycloneDX 1.5/1.6 classifiers (machine-learning-model,data).https://github.com/DependencyTrack/dependency-track/issues/4361 (accessed 2026-06). —Used for: basis that Dependency-Track does not yet ingest the model/data classifiers or modelCard (open as of this research).

A9. Protect AI.ModelScan — Static Scanner for Model Serialization Attacks (JSON reports, exit codes).https://github.com/protectai/modelscan (accessed 2026-06). —Used for: basis that model file serialization scanning is mature enough to insert into CI.

A10. Sigstore / OpenSSF.model-transparency (model-signing) — DSSE + in-toto Model Signing.https://github.com/sigstore/model-transparency (accessed 2026-06). —Used for: basis that model signing and provenance attestation map onto BOM integrity and provenance fields.

A11. Z. Tian et al. (2025).Data Poisoning in Deep Learning: A Survey.https://arxiv.org/html/2503.22759v1 (accessed 2026-06). —Used for: basis that data poisoning detection remains at the research stage with no general-purpose production tool.

A12. AboutCode.ScanCode Toolkit — License and Copyright Text Matching Engine.https://github.com/aboutcode-org/scancode-toolkit/ (accessed 2026-06). —Used for: basis for reusing the license identification engine while noting that AI license text needs to be added.

A13. Responsible AI Licenses (RAIL).FAQ / BigScience OpenRAIL-M — Use-Based Restrictions That Propagate to Derivatives.https://www.licenses.ai/faq-2 (accessed 2026-06). —Used for: basis that no standard exists for machine-reading and automatically determining RAIL-family conduct restrictions.

A14. LF AI & Data.Simplifying AI Model Licensing with OpenMDW.https://lfaidata.foundation/blog/2025/07/22/simplifying-ai-model-licensing-with-openmdw/ (accessed 2026-06). —Used for: basis that OpenMDW, a permissive license bundling models, data, and weights, is listed with SPDX (a candidate for the AI license dictionary).

A15. Protect AI.huntr — Bug Bounty and CNA for AI and ML.https://huntr.com/ (accessed 2026-06). —Used for: basis that CVEs issued by huntr flow into Dependency-Track matching via NVD.

A16. Google and OpenSSF.OSV.dev — Open Source Vulnerability Database.https://osv.dev/ (accessed 2026-06). —Used for: basis that OSV includes ML library vulnerabilities but does not record model-weight-specific risks themselves.

A17. Trail of Bits.Fickling — Static Analysis Tool for Pickle.https://github.com/trailofbits/fickling (accessed 2026-06). —Used for: basis for a high-risk pickle deep-inspection tool.

A18. OSS Review Toolkit.ORT — License Compliance Orchestration.https://github.com/oss-review-toolkit/ort (accessed 2026-06). —Used for: basis for reusing the policy rule engine and SBOM reporter.

A19. OpenSSF.GUAC — SBOM Graph and Impact Analysis.https://guac.sh/ (accessed 2026-06). —Used for: basis that it is an option for reinforcing impact analysis, while AI-specific handling remains unverified.

This checklist sets the criteria for vetting transparency and risk, on the basis of the AI Bill of Materials (AI BOM), when an in-house development team brings in and uses an external AI model or dataset. The items to check are drawn from the ingestion column of theAI BOM Field Requirements Matrix.

Because the purpose of an ingestion check is to bring a model in rather than to build one, fields that feed directly into risk assessment are prioritized. Licensing is the basis for judging compliance risk, provenance and sensitivity for judging data lawfulness and privacy risk, and vulnerability references for judging security risk.

1. AI BOM Presence and Format

• Is an AI BOM provided for the object being ingested?
• Is the format SPDX 3.0 or later, or CycloneDX 1.6 or later?
• Does the AI BOM’s timestamp match the version of the object being ingested?

If no AI BOM is provided, or the format lacks an AI-specific profile, request one from the supplier before ingestion, or secure the minimum information independently.

2. Identification and Version (Required Check)

3. License Check (Required Check)

An empty license field, or one that conflicts with the intended use, is grounds to hold off on ingestion. Because the model license and the dataset license are separate matters, check each independently.

4. Data Lawfulness and Risk (Required Check)

If the dataset’s provenance is unclear, or whether it contains sensitive data is not stated, data lawfulness and privacy risk must be assessed separately.

5. Security Risk (Required Check)

Vulnerability references are directly required by the Cyber Resilience Act and by US Food and Drug Administration guidance, so this is checked as required during ingestion vetting.

6. Recommended Checks

The following are checked additionally when the risk level is high or the use case is subject to regulation.

• Model timestamp and producer
• Model properties, input/output properties, training properties
• Model hash value and algorithm (integrity verification)
• Dataset contents and hash
• System data flow and data usage
• Whether the intended application domain matches our intended use

7. Ingestion Determination

Figure 5. Ingestion determination flow(synthesized from research)

If all the required check items in Sections 1 through 5 above are satisfied, the determination is ingestion approved. If any one of a license conflict, unclear provenance, undisclosed sensitive data, or an unacceptable vulnerability applies, the determination is held, and the supplier is asked to remedy the gap or an alternative model is considered.

The determination result is recorded together with the ingested object’s AI BOM identifier, version, and determination date, for use in subsequent reassessment and supply chain tracing.

This document sets out the guidelines for the AI Bill of Materials (AI BOM) that in-house development teams must produce when building an AI model or AI system. Information accessibility is at its best at the point of production, so this document sets the required level at its highest. The required fields are drawn from the production column of theAI BOM Field Requirements Matrix.

Much of the information that the production team fails to record can never again be obtained by the adopting team or by parties further down the supply chain. For that reason, model and dataset details that the consensus baseline treats as optional are recommended for production-time authoring.

1. Authoring Principles

The AI BOM is generated after model training or system build completes. The lifecycle stage at the time of generation (pre-build, build, or post-build) is recorded in the metadata. Use SPDX 3.0 or later, or CycloneDX 1.6 or later, as the format, and where possible generate it automatically with a generation tool, then fill in the missing items by hand.

Fields whose value cannot be determined must be marked “unable to confirm” rather than left blank. Whenever a model or dataset is updated, the AI BOM version and timestamp are updated together.

2. Required Fields

The following must always be filled in. These are the items for which two or more standards in the matrix require presence.

3. Recommended Fields

The following are optional under the consensus baseline, but since they can only be recorded accurately at the point of production, authoring them is recommended. If model cards and data cards are maintained, their contents should in particular be linked to the AI BOM.

4. Model Hashes and Integrity

The model hash value and algorithm are optional under the consensus baseline, but the recommendation is strong. Recording the hash of the weight file or model artifact lets downstream parties verify model integrity. For the hash algorithm, use hash function names from the Internet Assigned Numbers Authority (IANA), and use algorithms approved by the National Institute of Standards and Technology (NIST).

5. Dataset Provenance and Sensitivity

The production team knows the provenance of the training dataset best. Record the source, the collection method, the preprocessing and labeling steps, and whether synthetic data was used, and indicate whether personally identifiable information, copyrighted data, or sensitive data is included. This information serves as the basis for meeting the training data documentation obligations of the AI Act and the training data overview requirements of Korea’s Framework Act on Artificial Intelligence.

6. Post-Authoring Checklist

• Are all the required fields in Section 2 filled in?
• Among the recommended fields in Section 3, have those obtainable from model cards or data cards been linked?
• Are licenses stated separately for the model weights and for the dataset?
• Is the lifecycle stage at the time of generation recorded?
• When the model or dataset is updated, are the version and timestamp updated as well?

This document defines the requirements for the AI Bill of Materials (AI BOM) that a supplier providing AI models or AI systems to your organization must submit. It extends the existing Software Bill of Materials (SBOM) submission requirements to models and datasets, and the required items were derived from the supplier column of theAI BOM Field Requirements Matrix.

1. Standard Data Format

The AI BOM must be submitted in a machine-readable standard format. The following two formats are accepted.

Both formats are accepted on equal terms, but SPDX 3.0, which enforces the required properties of models and datasets at the format level, is recommended. CycloneDX below 1.6 and SPDX 2.x have no AI-specific profile and are not accepted as submission formats.

2. Information That Must Be Included

The following items must be included in every submitted AI BOM. Items whose values cannot be confirmed must not be left blank; they must be marked explicitly as “unknown.”

2.1 Document Metadata

2.2 System-Level Information

2.3 Model Information

2.4 Dataset Information

2.5 Security Information

Vulnerability referencing is optional under the consensus criteria, but it is treated as required for supplier submissions because the Cyber Resilience Act and U.S. Food and Drug Administration (FDA) guidance require it directly.

3. Identifier Rules

Models and datasets must be identified with machine-readable standard identifiers.

• Model identifiers use a Package URL (PURL) or Common Platform Enumeration (CPE). Native identifiers such as a model repository path or commit hash may be provided alongside these.
• Dataset identifiers use an accessible URL or URI.
• If multiple identifiers exist, all of them must be included.

4. Strengthened Requirements for Licensing, Provenance, and Sensitivity

Unlike existing software SBOM requirements, the AI BOM enforces the following three items with particular strictness.

Licensing must be stated separately for the model weights and the dataset. The submission must distinguish whether the model is open weight, open architecture, or open data, and must provide a link to the license document. Dataset provenance must go beyond a simple source statement to include the collection method (web crawling versus a commercial agreement), preprocessing and labeling steps, and whether synthetic data was used. Dataset sensitivity must indicate whether personally identifiable information, copyrighted data, or sensitive data such as financial or medical data is included.

5. Sample Document

The following is a minimal AI BOM skeleton in CycloneDX 1.6 format. An actual submission must fill in all the required items from Section 2 above.

{"bomFormat":"CycloneDX","specVersion":"1.6","metadata":{"timestamp":"2026-06-29T09:00:00Z","authors":[{"name":"Supplier legal name"}],"component":{"type":"application","name":"Supplied AI system","version":"1.0.0"}},"components":[{"type":"machine-learning-model","name":"Supplied model name","version":"1.0","bom-ref":"pkg:huggingface/org/model@1.0","supplier":{"name":"Model producer"},"licenses":[{"license":{"id":"Apache-2.0"}}],"modelCard":{"modelParameters":{"datasets":[{"type":"dataset","name":"Training dataset name","classification":"public","governance":{"owners":[{"organization":{"name":"Data source"}}]}}]}}}],"vulnerabilities":[]}

6. Pre-Submission Verification Checklist

Suppliers must confirm the following before submission.

• Is the format SPDX 3.0 or later, or CycloneDX 1.6 or later?
• Are all required items from Section 2 filled in, or explicitly marked “unknown”?
• Are the model and dataset identified with standard identifiers?
• Is a license stated for both the model weights and the dataset?
• Are dataset provenance and sensitivity indicated?
• Is a vulnerability reference link provided?
• Was it generated at a point in time after the build or model release was complete?

For detailed inspection criteria, see theIngestion Vetting Checklist.

Summary “Software Bill of Materials for AI — Minimum Elements,” published by the G7 Cybersecurity Working Group on May 12, 2026, is the first G7 joint guidance to reach agreement, at the level of 7 clusters and 50 elements, on what an SBOM applied to AI systems must contain. Germany’s BSI and Italy’s ACN co-led the effort, and it was published together with France’s ANSSI, Canada’s CSE, the United States’ CISA, the United Kingdom’s NCSC, and Japan’s NCO, alongside the European Commission. The document is a recommendation rather than an obligation and creates no new requirement, standard, or law, but by elevating AI models, datasets, and infrastructure to first-class tracked objects on top of the general SBOM, it becomes a reference point for national regulation and public procurement. For Korean companies and suppliers that adopt, develop, and deploy AI, it is worth reviewing in advance as a structural baseline for documents that respond to the EU Artificial Intelligence Act and the Cyber Resilience Act.

1. Overview

This document is the first G7 consensus document to define the minimum elements of an SBOM for AI at the item level. The issuing body is the G7 Cybersecurity Working Group, and the actual co-publishing agencies are seven: Germany’s Federal Office for Information Security (BSI), Italy’s National Cybersecurity Agency (ACN), France’s National Cybersecurity Agency (ANSSI), Canada’s Communications Security Establishment (CSE), the United States’ Cybersecurity and Infrastructure Security Agency (CISA), the United Kingdom’s National Cyber Security Centre (NCSC), and Japan’s National Cybersecurity Office (NCO). The European Commission joined as a collaborating bodyC1·C2. The publication date is May 12, 2026, and the United States’ CISA jointly announced the same document classified at the TLP:CLEAR information-sharing level (free to redistribute)C1·C2.

The work was co-led by Italy’s ACN and Germany’s BSI with the support of the G7 presidencies of Canada (2025) and France (2026), and the drafting period the text states runs from August 2025 to February 2026C1. The official published version can be downloaded from the BSI download page and the CISA resource libraryC1·C2.

The document’s status is clearly a recommendation. The text states explicitly that these minimum elements are not mandatory and create no new requirement, standard, or law, and describes the list of proposals as a non-exhaustive baseline that does not cover everythingC1. Although not binding, it carries weight for national regulation and public procurement requirements to reference, given that it was agreed by the cybersecurity authorities of all seven G7 countries together with the European Commission. Its scope of application is every developer and deployer that builds or deploys AI systems, and the document itself acknowledges that additional clusters or elements may be needed depending on industry, sector, and jurisdictionC1.

One point of terminology first. SBOM for AI, the term this document uses, is one of several names for the same object. The OpenChain project specifies AI SBOM as the abbreviation in its definitions clause, while CycloneDX uses Machine Learning Bill of Materials (ML-BOM), also written AI/ML-BOM depending on the documentB16. The industry also widely uses the general term AI BOM. The discussion below follows the original document’s usage, SBOM for AI, when referring to this document, and uses AI BOM only when referring to the general concept independent of any specific standard.

2. Core Content: The Seven Clusters and Elements

Because AI systems are also software systems, SBOM remains valid for AI, and the minimum elements of an SBOM for AI do not replace the general SBOM minimum elements but are added on top of themC1. What the document newly defines is a cluster system that divides the structured record into seven groups. Each cluster contains “elements” that capture the distinctive characteristics of AI system components. The metadata cluster concerns information about the SBOM itself, so it is presented first, and the remaining six clusters follow with equal weightC1.

Table 1. The seven clusters of an SBOM for AI. Metadata is the layer that describes the SBOM document itself, and the remaining six clusters are equally weighted information domains that make up the AI system. The 50 elements are divided across the 7 clusters.(G7 Software Bill of Materials for AI — Minimum Elements (2026-05-12); collected 2026-06-22)

2.1 Metadata: The Record of the SBOM Itself

The metadata cluster describes not individual components but the SBOM for AI itselfC1. It comprises 10 elements: author (SBOM author), version, data format name and version, author signature, tool name and version, generation context, timestamp, and dependency relationships. The author element refers to the entity that generated the SBOM, distinct from the Producer that made the component. The version element may use Semantic Versioning, in which case the major version of the published SBOM must be 1C1·B14. The author signature is recommended to use an algorithm approved by a relevant body, such as the NIST Digital Signature Standard (DSS), ISO/IEC 14888-4:2024, or an ENISA-agreed cryptographic mechanismB1·B3. The timestamp follows RFC 9557, and the identifier serial number follows RFC 9562B5·B4.

Two elements, generation context (SBOM generation context) and dependency relationship (SBOM dependency relationship), deserve particular attention in practice. Generation context marks the software lifecycle stage at which the SBOM was created, using references such as “before build,” “build,” and “after build.” An SBOM produced from source code falls under before build, and one produced by a binary analysis tool falls under after build. Dependency relationship goes beyond simple inclusion (“includes”/“included in”) to express that a given component is mostly derived from, or is a descendant of, other software, allowing backported or forked software to be recorded explicitlyC1.

2.2 System Level Properties (SLP): Where the Data Flows

The System Level Properties (SLP) cluster addresses the AI system as a whole. It captures, in 9 elements, the internal operation of a system composed of multiple elements such as classifiers, large language models (LLM), and AI agents; its software dependencies and frameworks; and how the system processes and interacts with user dataC1. Alongside basic identifying information such as system name and components, producer, version, and timestamp, it includes data flow, data usage, input/output properties, and intended application domain.

The most distinctive element is System data flow. It names, as examples, input/output endpoints, a description of the data information flow from source to destination, external service APIs, plus multi-agent communication protocols and web grounding, the bidirectional data flow toward external servicesC1. Drawing inter-agent communication and external web access into the data flow item signals that the tracking unit is not a single model but a composite system that interacts with the outside world. System data usage requires information such as whether the data is used to improve model performance and whether API calls log the data, captured via a link to technical documentation.

2.3 Models: How the Weights Were Made

The Models cluster, with the largest count at 13 elements, identifies the models an AI system uses and describes how their weights were generatedC1. It captures identifying information such as name, identifier, version, timestamp, and producer; integrity expressed as a hash value and hash algorithm; and the model’s character through model properties, input/output properties, training properties, license, and external references. Model identifier designates Common Platform Enumeration (CPE) or Package-URL (PURL) as the preferred identifier, while also permitting intrinsic identifiers such as UUID, commit hash, OmniBOR, and SWHIDB6·B7·B9·B10. The hash algorithm is identified by its IANA hash function textual name and is required to use a NIST-approved algorithmB12·B13.

Model training properties spans pretraining and post-training, fine-tuning, and continual learning, describing via a link to the model card everything from unsupervised/supervised/self-supervised learning types to reinforcement learning optimization types such as reinforcement learning from human feedback, instruction tuning, and Direct Preference OptimizationC1.

The Model license element is a distinctive contribution of the G7 document. Rather than merely naming the type of open source license, it requires stating separately which of open weight, open architecture, open data, and open training the model qualifies asC1.

Figure 1. The four axes that model license requires to be disclosed separately(based on Section 2.3 of the G7 “Software Bill of Materials for AI — Minimum Elements”).

Breaking openness, previously lumped together under the single word “open model,” into four axes serves to distinguish, at the SBOM level, the common case where only the weights are open while the training data or procedure remain closed. Disclosing weights and disclosing training data carry entirely different implications for licensing, reproducibility, and legal liability.

2.4 Datasets Properties (DP): Provenance and Sensitivity

The Datasets Properties (DP) cluster documents, in 10 elements, the identity and provenance of the datasets used across the model lifecycleC1. Basic information such as name, description, content, identifier, and hash is joined by provenance, statistical properties, sensitivity, dependency relationships, and license. Dataset provenance captures who contributed the data, the collection method — whether web crawling or commercial agreement — post-processing and pre-processing, labeling steps, and, for synthetic data, even its generation method. Dataset sensitivity indicates which of personally identifiable information (PII), freely accessible data, copyrighted data, sensitive data such as financial or medical data, and national-security-related data the dataset includes. This is a design aimed at tracking the legal and ethical risk of training data as an SBOM item.

2.5 Infrastructure: The Link to HBOM

The Infrastructure cluster captures, in two elements, the physical and virtual infrastructure essential to operating an AI systemC1. Infrastructure software lists dependencies such as firmware, package managers, third-party libraries, frameworks, and runtime environments. Infrastructure hardware, rather than directly describing specialized AI hardware, connects a dependency link to an existing Hardware Bill of Materials (HBOM). The structure whereby the software SBOM does not directly absorb hardware specifications but instead pulls in the HBOM by reference is a compromise that delegates the tracking of AI-accelerating hardware such as GPUs to a separate standard while still leaving a connecting link.

2.6 Security Properties (SP) and Key Performance Indicators (KPI)

The Security Properties (SP) cluster addresses, in 4 elements, the cybersecurity measures applied to the AI model and systemC1. Security controls lists, distinguishing between them, general controls such as encryption, data minimization, differential privacy, and access control, and AI-specific controls such as adversarial robustness training, prompt injection controls, and training data curation. Security compliance covers certifications and standards obtained, cybersecurity policy information links to a security.txt file, and Vulnerability referencing carries a link to a database of the exploitability of known vulnerabilities.

The Key Performance Indicators (KPI) cluster is a grouping unique to G7 that has no counterpart in the general SBOM. Security metrics covers security benchmarks such as resilience against third-party manipulation, and Operational performance KPIs covers system uptime, incident resolution time, latency, request throughput, and load balancingC1. This is an attempt to capture, in the SBOM, not just a static list of configuration but also operational status and threat indicators, and, as seen later in Section 4, it is also the area that draws the most criticism for measurement consistency.

3. Background and Context

This document exists now because two separate lineages converged at a single point. One is the general SBOM minimum elements institutionalized in the United States, and the other is the vision for an SBOM for AI that the G7 sketched out in 2025.

Figure 2. The standardization progression from general SBOM to AI SBOM(compiled for this report).

The reference point for the general SBOM minimum elements is “The Minimum Elements for a Software Bill of Materials,” published in July 2021 by the U.S. Department of Commerce’s National Telecommunications and Information Administration (NTIA) under the direction of Executive Order 14028. That document presented seven data fields — supplier name, component name, version, unique identifier, dependency relationship, SBOM author, and timestamp — and stewardship of the SBOM community’s ongoing work was subsequently transferred to CISAC7. Evidence that the G7 document directly continues this lineage shows up in how the metadata cluster is defined. Author, version, data format, timestamp, and dependency relationship carry the NTIA data fields almost unchanged into the AI context, and the fact that the Model identifier designates CPE and PURL as preferred identifiers while citing CISA’s “Software Identification Ecosystem Option Analysis” (2023) shows the same rootsC6·C7.

The direct starting point is the 2025 vision document. “A shared G7 vision on Software Bill of Materials for AI” was published by BSI and ACN in June 2025 and endorsed at the Ottawa G7 meeting; it defined the concept, goals, benefits, and properties of an SBOM for AI and went no further than presenting the seven clusters as high-level examplesC3. At the same time, experts recommended that each cluster be defined in detail, and the 2026 minimum elements document is that follow-up. If the vision was the outline of “what must be captured,” this document is the detail of “which elements, defined how, go into each cluster”C1·C3.

The difference lies in drawing AI-specific components in as first-class tracked objects. Where the general SBOM targets identification of software components, the G7 document adds five groupings: models, datasets, infrastructure, security properties, and key performance indicators. The reason for this expansion is that code alone cannot express the training process, the data, and model behavior. Breaking model license into four axes and having dataset provenance capture even the collection method and, for synthetic data, the generation method are items that did not exist in the general SBOM.

On implementation, the document is format-neutral. Placing the data format name and version elements in the metadata cluster is evidence of this, and actual implementation is carried by two existing BOM standards. SPDX (System Package Data Exchange), a Linux Foundation project, introduced AI and dataset profiles starting with 3.0 (April 2024), defining model type and architecture, hyperparameters, autonomy type, and whether sensitive information is used, among othersB15. CycloneDX (OWASP) has supported the Machine Learning Bill of Materials (ML-BOM) since 1.5, capturing training approach, architecture, performance, and ethical considerations through a modelCard objectB16. The G7 document’s note, in the model license example, that one “can point to the corresponding field in the SPDX/CDX file,” shows that it presupposes these two formats as the implementation mediumC1.

4. Recent Developments and Verification Challenges

Looking at the reaction in the roughly one month following publication, broad agreement gathered around the direction of the seven clusters, but a gap emerged over measurability and verifiability. The announcement took the form of simultaneous publication by BSI, CISA, ANSSI, ACN, CSE, NCSC, and NCO together with the European Commission, and ANSSI, in an English-language post on May 13, 2026, introduced the document as “concrete guidance on what can reasonably be expected of an SBOM for AI” while noting the possibility of future adjustmentA4. Trade press coverage concentrated on May 13–14, and the law firm Morgan Lewis, in a June analysis, emphasized that the guidance is voluntary and non-bindingE1.

Questions about measurability were the common focus of commentary. Allan Friedman, CISA’s former SBOM lead, affirmed much of the seven clusters while noting that many “are difficult to even measure or define in a concrete, organization-consistent way”A6. Sanchit Vir Gogia of Greyhound Research summarized that “the minimum elements create visibility but not assurance,” and Nigel Douglas of Cloudsmith likewise noted, while acknowledging that the document raises the right requirements, the limitation that the seven data clusters are hard to measure consistently across organizationsA10·A8. TLCTC, a security threat classification framework, criticized the Security Properties (SP) cluster head-on the same day the document was published, pointing out that while it lists control items, it does not state which threat each control addresses, which reduces auditabilityA11.

Standard and tool implementations do not yet fully fill the G7’s seven clusters. The SPDX dataset profile’shasSensitivePersonalInformation andconfidentialityLevel map to G7’s dataset sensitivity, anddataCollectionProcess maps to dataset provenanceB15·A13. By contrast, the metadata cluster’s author signature and generation context, and the KPI cluster’s operational performance indicators (uptime, latency, throughput), have no clearly structured, dedicated field in either standard, requiring a workaround through external references or free textA13·A16. The SP cluster’s AI-specific controls similarly lack adequate structured fields.

It is particularly worth noting that the G7’s judgment on agentic AI and the movement of the standards community diverged. The document’s Discussion section explicitly addressed whether to add the decision-making level, or autonomy, of an AI system as a separate element. The working group acknowledged that the rapid advance of agentic AI could increase the importance of this element and that it could help in assessing the impact of a compromise, but decided not to specify autonomy as a separate element, on the grounds that this element might be handled differently across jurisdictions through mechanisms such as safety requirementsC1·A7. The standards community moved in the opposite direction over the same period. SPDX 3.1, unveiled at FOSDEM in February 2026, added AI agents and retrieval-augmented generation (RAG) as first-class concepts, with the data format providing vocabulary ahead of the area where policy consensus had held backA14. How the G7’s future refinement work absorbs this standard vocabulary is worth watching.

Regulatory alignment remains an open question. On the publication date, the primary source, the BSI publication page, states May 12, and the May 13 date given by some outlets appears to stem from differences in time zone and posting timeA3·A4. Mapping the fields between the voluntary G7 recommendation and the soon-to-be-binding EU obligations is the next task for corporate practice.

5. Implications for Korean Readers

The first thing to confirm is not a reporting obligation but a signal of documentation-structure standardization. The G7 minimum elements themselves impose no direct legal obligation in any countryC1. However, the EU Artificial Intelligence Act requires the technical documentation of Article 11 and Annex IV for high-risk AI systems, and that obligation applies from August 2, 2026 for the high-risk systems of Annex IIIA1. The components, data, and performance documentation Annex IV requires overlap substantially with the G7’s System Level Properties, Models, and Datasets clusters. For a Korean company supplying AI products to the EU, it is practical to use the G7 clusters as a checklist of technical documentation items and fill in the gaps in advance.

The Cyber Resilience Act (CRA) directly mandates an SBOM. Annex I, Part II(1) requires that the components of a product with digital elements be documented in an SBOM in a machine-readable format, with the vulnerability and incident reporting obligation (Article 14) applying from September 11, 2026, and the remaining core requirements applying from December 11, 2027A2. The G7 document’s choice to build a structure that stacks AI elements on top of the general SBOM meshes naturally with the SBOM obligation foundation the CRA has already laid. A company launching AI-equipped products in the EU would do well to prepare a two-layer structure: the general SBOM (CRA obligation) plus the G7 AI elements on top.

On preparation, the highest-priority items are datasets and model license. Dataset provenance and sensitivity (PII, copyright, national security) bear directly on the legal risk of training data, so an organization that draws on external models and data all the more needs a procedure for requiring this information from its suppliers. The four-axis breakdown of model license (weights, architecture, data, training procedure) becomes the criterion that distinguishes, when adopting an “open model,” what is actually disclosed and what constraints apply to redistribution, fine-tuning, and commercial use. Because the data flow element of System Level Properties covers even inter-agent communication and web grounding, for systems that use external APIs and multiple agents, specifying where data goes becomes both a regulatory response and a security check.

Risk and opportunity sit in the same place. The criticism that the minimum elements do not guarantee measurement and verification is a warning that simply filling in the items does not by itself ensure agreement with the actual systemA8·A10. The G7 document itself emphasizes that an SBOM not connected to vulnerability scanning and management tools and to security advisories remains no more than a paper documentC1. Conversely, adopting this cluster framework early for asset inventory and supply chain checks can lower conversion costs once EU and U.S. regulation becomes more concrete, and can turn supply chain transparency into a differentiator.

6. Relationship to Other Reports in This Workspace

This report addresses a different layer than this workspace’s general AI BOM report and its OpenChain report. The AI BOM report (reports/ai-bom) is the overview and regulatory-mapping layer, broadly covering the history of SBOM, AI BOM in general, and mapping to EU regulation. The OpenChain AI SBOM report (reports/openchain-ai-sbom) covers the process and compliance layer — the compliance process that extends ISO 5230 to AI, that is, how an organization generates and manages an SBOM. The distinctive value of this G7 report is the data-definition layer that sits between them: the item-level specification of exactly which elements, defined how, an SBOM must contain. The three reports complement one another as the general account (why and what), the process (how to manage), and the element definitions (exactly what to record). If you are actually designing an AI BOM adoption, the natural combination is to set the context with the general account, build the operating process with OpenChain, and fill in the recorded items with the G7 clusters.

7. References

Only sources cited in the body are listed. All URLs were accessed and verified on 2026-06-22.

Legislation and Regulation (Primary)

A1. European Parliament and Council (2024).Regulation (EU) 2024/1689 (Artificial Intelligence Act). OJ L, 2024/1689, 12.7.2024.https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng (accessed 2026-06-22; ELI permanent link. The August 2, 2026 application date for high-risk systems was cross-checked against the European Commission’s policy page). —Use: obligation for high-risk AI technical documentation and correspondence with the G7 clusters.↩

A2. European Parliament and Council (2024).Regulation (EU) 2024/2847 (Cyber Resilience Act, CRA). OJ L, 2024/2847, 20.11.2024.https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed 2026-06-22; ELI permanent link). Supplemented for the Annex I Part II(1) and Article 14 (2026-09-11) / Annex I (2027-12-11) application schedule by Anchore’s explainer on CRA SBOM requirements:https://anchore.com/sbom/eu-cra/ (accessed 2026-06-22). —Use: legal basis and application schedule for the SBOM-creation obligation.

Standards and Specifications (Primary)↩

B1. National Institute of Standards and Technology (2023).FIPS 186-5: Digital Signature Standard (DSS). February 2023.https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf (accessed 2026-06-22). —Use: basis for the approved algorithms for the author signature element (original document footnote 4).↩

B3. ISO/IEC (2024).ISO/IEC 14888-4:2024, Information security — Digital signatures with appendix — Part 4: Stateful hash-based mechanisms.https://www.iso.org/standard/80492.html (accessed 2026-06-22; the ISO page returns 403 to automated tools, so the standard number and title were confirmed from ISO search results). —Use: basis for the approved signature mechanisms for the author signature element.↩

B4. Internet Engineering Task Force (2024). Davis, K., Peabody, B., Leach, P.RFC 9562: Universally Unique IDentifiers (UUIDs). May 2024.https://www.rfc-editor.org/rfc/rfc9562.html (accessed 2026-06-22). —Use: identifier serial-number standard for SBOM version (original document footnote 3).↩

B5. Internet Engineering Task Force (2024). Sharma, U., Bormann, C.RFC 9557: Date and Time on the Internet: Timestamps with Additional Information. April 2024.https://www.rfc-editor.org/rfc/rfc9557.html (accessed 2026-06-22). —Use: format for SBOM timestamp (original document footnote 6).↩

B6. NIST, National Vulnerability Database.Official Common Platform Enumeration (CPE) Dictionary.https://nvd.nist.gov/products/cpe (accessed 2026-06-22). —Use: CPE as a recommended identifier for Model identifier (original document footnote 8).↩

B7. Ecma International (2025).ECMA-427: Package-URL (PURL) Specification, 1st Edition. December 2025.https://ecma-international.org/publications-and-standards/standards/ecma-427/ (accessed 2026-06-22). —Use: PURL as a recommended identifier for Model identifier (original document footnote 9).↩

B9. OmniBOR Project.OmniBOR Specification.https://omnibor.io/ (accessed 2026-06-22). —Use: OmniBOR as an example intrinsic identifier for Model identifier (original document footnote 10).↩

B10. SWHID Project.The SWHID Specification Version 1.2.https://www.swhid.org/specification/v1.2/ (accessed 2026-06-22). —Use: SWHID as an example intrinsic identifier for Model identifier (original document footnote 11).↩

B12. Internet Assigned Numbers Authority.Named Information Hash Algorithm Registry (Hash Function Textual Names).https://www.iana.org/assignments/named-information/named-information.xhtml (accessed 2026-06-22). —Use: recommendation for identifying Model hash algorithm (original document footnote 12).↩

B13. NIST, Computer Security Resource Center.Hash Functions (project).https://csrc.nist.gov/projects/hash-functions (accessed 2026-06-22). —Use: basis for NIST-approved algorithms for Model hash algorithm (original document footnote 13).↩

B14. Preston-Werner, T. and the SemVer Team (2013).Semantic Versioning 2.0.0.https://semver.org/ (accessed 2026-06-22). —Use: Semantic Versioning for SBOM version (original document footnote 2).↩

B15. SPDX Project.SPDX 3.0.1 Specification — AI Profile. Linux Foundation.https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/ (accessed 2026-06-22). —Use: data-format implementation of the SBOM for AI, cluster correspondence.↩

B16. OWASP CycloneDX.Machine Learning Bill of Materials (ML-BOM / AI-BOM) capabilities.https://cyclonedx.org/capabilities/mlbom/ (accessed 2026-06-22). —Use: an alternative implementation of the SBOM for AI (ML-BOM / modelCard).

Government and Agency Guidance and Official Publication Sources (Primary)↩

C1. G7 Cybersecurity Working Group (2026).Software Bill of Materials for AI — Minimum Elements (BSI official publication). Published 2026-05-12.https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.html (accessed 2026-06-22; direct PDF linkhttps://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.pdf). —Use: the source document. The primary basis for all cluster and element definitions.↩

C2. G7 Cybersecurity Working Group / CISA et al. (2026).Software Bill of Materials for AI — Minimum Elements (TLP:CLEAR, CISA joint publication). Published 2026-05-12.https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements (accessed 2026-06-22; the CISA page returns 403 to automated tools, so the fact and date of publication, the TLP:CLEAR classification, and the seven clusters were cross-checked against search results and a WaterISAC notice). —Use: confirmation of the U.S. official publication, the TLP:CLEAR distribution status, and the co-publishing agencies.↩

C3. G7 Cybersecurity Working Group (2025).A shared G7 vision on Software Bill of Materials for AI (Shared G7 Vision, 2025-06). Published by ACN.https://www.acn.gov.it/portale/documents/d/guest/paper_sbom-for-ai_19may2025_-clean-2 (accessed 2026-06-22). —Use: the preceding vision document, the first proposal of the seven clusters (original document footnote 1).↩

C6. Cybersecurity and Infrastructure Security Agency (2023).Software Identification Ecosystem Option Analysis. 2023-10-26.https://www.cisa.gov/sites/default/files/2023-10/Software-Identification-Ecosystem-Option-Analysis-508c.pdf (accessed 2026-06-22; the CISA site returns 403 to automated tools; the document’s existence and date match the original document’s footnote 7). —Use: basis for the software identification ecosystem referenced by Model identifier (original document footnote 7).↩

C7. National Telecommunications and Information Administration (2021).The Minimum Elements for a Software Bill of Materials (SBOM). 2021-07-12.https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf (accessed 2026-06-22; automated tools encounter a certificate error, alternate publication sourcehttps://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom). —Use: the general SBOM minimum elements that the SBOM for AI builds on.

Industry and Law Firm Analysis, and Press Coverage (Secondary, Cross-Checked Against Primary Sources)↩

A3. BSI (2026).Software Bill of Materials (SBOM) for Artificial Intelligence — Minimum Elements (publication page). States a publication date of 2026-05-12.https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.html (accessed 2026-06-22). —Use: primary confirmation of the publication date.↩

A4. ANSSI (2026).Software bill of materials (SBOM) for artificial intelligence (English-language post, 2026-05-13).https://cyber.gouv.fr/en/publications/jointly-led-international-publications/software-bill-of-materials-sbom-for-artificial-intelligence/ (accessed 2026-06-22). —Use: primary commentary from a publishing agency.↩

A6. Infosecurity Magazine (2026-05-13).Global Cyber Agencies Issue New SBOMs for AI Guidance.https://www.infosecurity-magazine.com/news/new-sboms-for-ai-guidance-2026/ (accessed 2026-06-22). —Use: citation of Friedman’s commentary.↩

A7. Industrial Cyber (2026-05-13).CISA, G7 partners release SBOM for AI guidance…https://industrialcyber.co/sbom/cisa-g7-partners-release-sbom-for-ai-guidance-to-boost-ai-supply-chain-transparency-and-cybersecurity-resilience/ (accessed 2026-06-22). —Use: coverage of the cluster and autonomy discussion.↩

A8. SecurityWeek (2026-05-14).G7 Countries Release AI SBOM Guidance.https://www.securityweek.com/g7-countries-release-ai-sbom-guidance/ (accessed 2026-06-22). —Use: commentary from Douglas (Cloudsmith).↩

A10. CIO (2026-05-13).CISA’s AI SBOM guidance pushes software supply-chain oversight into new territory.https://www.cio.com/article/4170711/cisas-ai-sbom-guidance-pushes-software-supply-chain-oversight-into-new-territory-2.html (accessed 2026-06-22). —Use: expert commentary on the measurement and verification gap (Gogia and others).↩

A11. TLCTC (2026-05-12).The Control Fixation in the Security Properties — A TLCTC critique of G7 SBOM-for-AI.https://www.tlctc.net/sbom-for-ai-control-fixation.html (accessed 2026-06-22; WebFetch returned 403, confirmed via a search cache). —Use: critique of the SP cluster.↩

A13. Bennet, K., Rajbahadur, G., Suriyawongkul, A., Stewart, K. (2024-10).Implementing AI Bill of Materials (AI BOM) with SPDX 3.0. Linux Foundation. DOI 10.70828/RNED4427.https://www.linuxfoundation.org/hubfs/LF%20Research/lfr_spdx_aibom_102524a.pdf (accessed 2026-06-22). —Use: analysis of SPDX field selection and gaps.↩

A14. SPDX AI Working Group (2026).Publications — FOSDEM 2026 (2026-02-01) SPDX 3.1 announcement.https://fosdem.org/2026/schedule/event/9Q9EEL-what_is_new_in_spdx_3_1_which_is_now_a_living_knowledge_graph/ (accessed 2026-06-22). —Use: SPDX 3.1’s addition of AI Agent, Prompt, and RAG.↩

A16. OWASP CycloneDX.Inventory Management Use Case: AI Models and Model Cards.https://cyclonedx.org/use-cases/ai-models-and-model-cards/ (accessed 2026-06-22). —Use: field gaps in ML-BOM and model cards.↩

E1. Morgan Lewis (2026-06-16).US CISA, G7 Partners … Release Minimum Elements for AI Software Bills of Materials.https://www.morganlewis.com/pubs/2026/06/us-cisa-g7-partners-in-europe-and-asia-release-minimum-elements-for-ai-software-bills-of-materials (accessed 2026-06-22; key facts cross-checked against C1/C2). —Use: analysis of regulatory alignment.↩

Summary This report analyzesArtificial Intelligence System Bill of Materials — Compliance Management Guide for the Supply Chain, written by the AI Work Group (OpenChain AI Work Group) of the OpenChain Project under the Linux Foundation. The guide carries the methodology of ISO/IEC 5230, the international standard for software license compliance, over to the artificial intelligence (AI) supply chain, defining the core requirements a quality AI SBOM compliance program must meet. Its purpose is to provide a common baseline for trust between organizations that exchange AI solutions, and it extends traditional SBOM compliance by pulling not just code but model weights, training datasets, and the licensing and transparency obligations of the Model Tree into the scope of tracking. For Korean companies and practitioners preparing for AI supply chain governance, it serves as a checklist asking “what must be documented and demonstrated.”

The text this report analyzes is a working copy (RFC draft) from the/docs directory of theOpenChain-Project/AI-WG repository on GitHub. As confirmed in the trend research, the same document went through six weeks of public comment and was formally published as OpenChain AI SBOM Compliance Guide Version 1 on October 20, 2025A9. This report therefore covers not the formal Version 1 but an earlier draft snapshot. The citable formal edition is published as PDF and Markdown in the OpenChain Reference-Material repositoryA9·A12. A full-text comparison of the two documents on July 20, 2026 found that the nine normative (shall) provisions covered below and the section structure remain identical in wording in the formal edition. However, four definitions (2.5 Identified License, 2.6 Program, 2.7 Program Participant, 2.8 Supplied Software) were reworded in the formal edition, so these definitions should be checked directly against the formal text when cited.

1. Document Overview

This guide defines the core requirements a quality AI SBOM compliance program must meet. It was published by the AI Work Group of the OpenChain Project under the Linux Foundation, and is the product of an open working group operated through a mailing list anyone can join for free and regular workshopsA1·A2. The license the document specifies is Creative Commons Attribution 4.0 (CC-BY-4.0)A1.

The guide’s design intent is clear from its overview. It focuses on the “what” and “why” of a program rather than the “how” and “when,” leaving flexibility for organizations of different sizes operating in different markets to choose the specific policies and procedures that fit their own scale, goals, and scopeA1. The guide states that it drew inspiration from OpenChain ISO/IEC 5230, applying its lessons to the market need for AI SBOM management in the supply chain. In preparing it, ISO/IEC 5230:2020, ISO/IEC 42001:2023, and ISO/IEC 5962:2021 were cited as reference standardsA1.

The document’s status is an RFC (Request for Comments) draft. The NOTICE at the top states plainly that it is not a production release but “a working document for interested parties to share ideas” and a “living document”A1. The relationship between the draft and the formal edition is a matter of timing. After reviewing the draft, the OpenChain AI Work Group opened a public comment period on July 7, 2025, closed it and reviewed the comments on August 18, 2025, and, following a decision by the Governing Board, formally published Version 1 on October 20, 2025A10·A11·A9. The RFC.docx inAI-WG/docs that this report covers is that working copy, and the formal edition for external citation is published separately in the Reference-Material repositoryA12. The difference in license notation between the two texts (the working copy is CC-BY-4.0 per the document’s NOTICE) stems from the difference in distribution stage.

2. Background: Extending the OpenChain Methodology to AI

The OpenChain Specification is a process management standard that defines the requirements a quality open source license compliance program must meet. Developed by roughly 100 contributors between 2014 and 2016, it launched as Version 1.0 in October 2016, then, through ISO/IEC JTC 1’s Publicly Available Specification (PAS) Transposition procedure in April 2020, became the international standard ISO/IEC 5230:2020 in December of the same yearA14·A3. OpenChain also extended the same framework into the security domain, standardizing an open source security assurance specification focused on checking for disclosed security vulnerabilities as ISO/IEC 18974:2023A13.

The core of the 5230 methodology is the structure it uses to describe requirements. Each requirement consists of Verification Materials — the records that must be produced to demonstrate that the requirement was met — and a Rationale explaining why the requirement is neededA14. This design, which fixes only the outcome and purpose while leaving the means of implementation open, is the basis for its non-prescriptive character, which allows organizations of different sizes and markets to shape a program that fits them. The fact that the AI SBOM guide repeats the “Verification Materials + Rationale” structure in every section is a direct carryover of this methodology.

In AI systems, what must be tracked extends beyond code. Model weights, the datasets used for training, testing, and validation, and even the Model Tree — which represents the relationship of one AI system being derived from several others — can each carry their own license. This is why the guide’s License Obligations (3.5) and Transparency Obligations (3.6) discuss code, weights, and datasets together. Where open source compliance asks “which component came in under which license,” AI requires extending that same question to models and data. The process-centered, non-prescriptive philosophy of 5230 suits this extension well. In an environment where the regulatory landscape is splitting rapidly by jurisdiction, fixing only “what must be demonstrated” instead of pinning down specific procedures lets organizations under different regimes — the European Union, the United States, China — share the same common baseline.

A Software Bill of Materials (SBOM) is a formal record of the components that make up a piece of software and their supply chain relationships. In the United States, Executive Order 14028 on Improving the Nation’s Cybersecurity directed the definition of SBOM minimum elements in May 2021, and the National Telecommunications and Information Administration (NTIA) publishedMinimum Elements for a Software Bill of Materials on July 12, 2021D4·D1. Traditional SBOMs are designed to identify and track software components, making them ill-suited to representing training processes, data, and model behavior as such. The AI SBOM the guide defines is “a list of components that make up part or all of an AI system, and related information about them,” explicitly including models and datasets. The industry also calls the same concept an AI BOM or a Machine Learning Bill of Materials (ML-BOM). The names diverge because each standard has set its own terminology. The guide specifies AI SBOM as its abbreviation in definition clause 2.2A1, while the G7 cybersecurity working group calls the same thing SBOM for AI, and CycloneDX calls it ML-BOM. This report uses AI SBOM when referring to the guide, and uses AI BOM only when discussing the general concept without tying it to a specific standard.

In terms of format, the guide leaves the door open to SPDX, CycloneDX, or any other format. SPDX (System Package Data Exchange) is an exchange standard internationalized as ISO/IEC 5962:2021; SPDX 3.0, released on April 16, 2024, introduced an AI Profile and a Dataset Profile that let it express information such as model type, hyperparameters, training data preprocessing, energy consumption, and safety risk assessmentsA5·B6·B2. CycloneDX is a full-stack BOM standard maintained by OWASP; it introduced ML-BOM in version 1.5, requiring documentation of datasets and models, configuration and training data provenance, ethical considerations, bias, and model security risksB5. The two formats use different representation models but target the same problem by treating models and datasets as first-class components.

It is also worth noting that the guide’s footnotes repeatedly reference ISO/IEC 42001:2023. 42001 is the first international standard for an AI Management System (AIMS), specifying the requirements for establishing, operating, and improving one, and its Annex B describes how to implement controls by stage of the AI lifecycleA4. If the OpenChain methodology defines “what must be demonstrated,” 42001 Annex B supplies the specific control items for “what must be documented and operated to demonstrate it.” The guide does not replace 42001; rather, it cites specific clauses of Annex B (B.2.2, B.3, B.4.2, B.4.6, B.5.3, B.6.2, B.8.5, B.9.3, and others) and main text clause 7.3 as the rationale for its Competence, Awareness, Resources, Governance, and SBOM sectionsA4.

3. Structure and Requirements of the Guide

The body of the guide (Chapter 3, Guidance) consists of ten requirement sections. Every section repeats the three-part 5230 pattern: requirement statement, verification materials, and rationale. As a footnote notes, what a specification would call “Requirements” this document calls “Guidance,” to make clear that the items are recommendations rather than normative mandatesA1.

Grouping the requirements by meaning yields two families. One is the program governance skeleton inherited directly from ISO/IEC 5230 (Policy, Competence, Awareness, Scope, Resources, Access); the other is the territory newly extended because of AI (License Obligations, Transparency Obligations, AI SBOM, AI Governance). Figure 1 shows this cluster structure.

Figure 1. Six inherited, four extended for AI(based on OpenChain AI SBOM Compliance Guide body 3.1-3.10, as of 2026-06-12)

Table 1 summarizes the core of each requirement. The “Enforcement Level” column carries over the RFC 2119 keywords (shall, should, and so on) that the guide’s body text uses; their definitions are drawn, per the guide’s Chapter 2, from IETF RFC 2119A1·A6.

Table 1. Summary of the guide’s ten requirements(based on OpenChain AI SBOM Compliance Guide body 3.1-3.10, 2026-06-12)

The License Obligations (3.5) section best reveals the character of the AI extension. The review scope covers not just code but the licenses of weights, training/test/validation datasets, and the AI system itself, and it requires reviewing and documenting the obligations, restrictions, and rights spanning upstream and downstream on the Model TreeA1. This section cites 5230:2020 Section 3.3.2 as its basis and references 42001 Annex B.2.2 as an example. The AI SBOM (3.9) section leaves the format open — SPDX, CycloneDX, or otherwise — but requires at the shall level that inbound materials (models, datasets, and the like flowing in from third parties) be reflectedA1·B2. The Governance (3.10) section names the EU AI Act, the Hiroshima AI Process, and China’s Global AI Governance Initiative directly as examples of emerging regulation, and covers the ability to monitor the AI system lifecycle alongside ethical considerations, risk management, and transparencyA1.

4. Regulatory and Governance Trends

All three pillars named in the guide’s Governance section saw meaningful progress around the research reference date (2026-06-12). Above all, the guide itself was published as Version 1 on October 20, 2025A9.

The EU AI Act (Regulation (EU) 2024/1689) is the first pillar. It applies in stages, and as of the research reference date only some provisions had come into effect. Table 2 summarizes the application schedule.

Table 2. EU AI Act phased application schedule(source: Regulation (EU) 2024/1689 Article 113 / EUR-Lex, European Commission, accessed 2026-06-12)

Obligations for General-Purpose AI (GPAI) model providers began applying on August 2, 2025, but the point at which the European Commission can actually exercise its enforcement powers, including fines, is August 2, 2026C1·C6. Annex III high-risk AI system obligations and transparency obligations also apply from the same date. This August 2026 application date is the backdrop for why the guide’s Section 3.6 requires reviewing “transparency obligations imposed by regulation.” Its point of contact with AI SBOM is the technical documentation required under Article 11 and Annex IV of the AI Act; this requirement, which takes effect from August 2026, is cited as a driver pushing AI BOM from an optional security artifact toward a de facto procurement requirementC1.

The second pillar, the Hiroshima AI Process, began during Japan’s G7 presidency in 2023 and produced the International Code of Conduct for organizations developing advanced AI; the Organisation for Economic Co-operation and Development (OECD) operates the HAIP Reporting Framework as its implementation-tracking mechanismC4. Version 1.0 launched on February 7, 2025, and the OECD announced Reporting Framework 2.0 on May 28, 2026, on the occasion of the G7 Digital and Technology Ministers’ Meeting in ParisC4·C7. Version 2.0 simplified procedures to broaden participation by small and medium-sized enterprises and introduced a role-based structure distinguishing model developers, application developers, and deployers; more than 50 organizations have indicated they will report under the new framework (the next analytical review submission deadline is 2026-09-01)C7. What the guide calls “Hiroshima AI Process compliance” refers to participation in this voluntary reporting framework.

The third pillar, China’s Global AI Governance Initiative, is a policy declaration announced in October 2023 on the occasion of the Belt and Road Forum for International Cooperation in Beijing. Unlike the EU AI Act or the Hiroshima Process, it does not define a specific reporting format or compliance deliverable, so there is currently no directly corresponding obligation item from an AI SBOM standpoint. The guide mentions it only in passing, as one example of emerging AI regulation.

Format standards have moved as well. SPDX introduced its AI and Dataset profiles with SPDX 3.0 in April 2024, and CycloneDX introduced ML-BOM in v1.5 in June 2023, then released v1.7 (ECMA-424 2nd edition) in October 2025 as the final release of the 1.x seriesB6·B5. Generation tools have also appeared. In 2025, OWASP released the OWASP AIBOM Generator, which automatically generates a CycloneDX-format AI SBOM from a Hugging Face model and scores its completenessB7, and CycloneDX’s cdxgen also supports a dedicated AI BOM modeB8. However, these tools merely carry over the license stated on a model card without guaranteeing its accuracy, and the OWASP AIBOM project is separately assessing the gap where SPDX and CycloneDX do not yet fully cover AI-specific use casesE6.

5. Significance and Limitations

The value of this guide lies in specifying “the minimum requirements an AI supply chain compliance program must meet” on top of a methodology already validated as an ISO international standard. Thanks to the 5230-style structure that attaches verification materials and rationale to every section, an organization can turn each requirement into its own checklist and directly check “do we have this artifact.” The non-prescriptive design — leaving the format open to SPDX, CycloneDX, and others, and delegating the specifics of procedure to the organization — is a practical choice that provides a common baseline in an environment where regulation is splitting by jurisdiction.

The limitations are also clear. The license and transparency tracking the guide requires is difficult in practice. One study that quantified license drift — the loss of obligations as a model propagates downstream — reports that about 35.5% of transitions from model to application lose their restrictive clauses and get reassigned to a permissive license, and that machine-learning-specific obligations are preserved in only 0.4% of cases after downstream integrationE4. The Responsible AI License (RAIL) family and the Llama Community License carry behavioral use clauses that keep them from meeting the Open Source Initiative (OSI)’s Open Source Definition, and tools to track compliance with these non-standard licenses are still lackingE8·E5. The guide’s Section 3.5 requirement to review licenses beyond code, down to weights and datasets, is a design that reflects this reality. Several tools already exist to generate AI SBOMs automatically, but verifying whether the licenses in a generated bill of materials are accurate, and whether the usage restrictions of non-standard licenses are being honored, is still left to people and policy. As of 2026, what remains between requirement and feasibility is not a generation gap but a verification gap.

It is both a limitation and a feature that the guide defines itself as a living document and, by numbering itself Version 1, presupposes future revisions. Because this is a domain where regulation and format standards change quickly, the guide too is not a fixed specification, and as of the research reference date no schedule for the next revision had been published.

6. Process Requirements and Data Item Requirements

What this guide defines is the process layer of compliance. It focuses on the minimum requirements a program must meet — does a policy exist, are competence and resources assigned, is there a procedure to generate and manage AI SBOMs. A distinct, separate layer is data items. What items regulation actually requires an AI BOM to contain — as with the technical documentation required by Article 11 and Annex IV of the EU AI Act — must be worked out through separate mapping workC1. Only by combining the procedures the guide’s Sections 3.5 (License Obligations), 3.6 (Transparency Obligations), and 3.9 (AI SBOM) require in the abstract with the specific items each regulatory provision requires to be recorded do process requirements and data item requirements connect into a single system.

References

Only the sources cited in the body text are organized here as paragraphs, following the unified label scheme in 03-references.md. For the full source list and automated verification notes, see 03-references.md in the same folder.

A. Primary Source and OpenChain/Standards

A1. OpenChain Project AI Work Group (2024).Artificial Intelligence System Bill of Materials — Compliance Management Guide for the Supply Chain (RFC Draft, CC-BY-4.0 per document NOTICE). GitHubOpenChain-Project/AI-WG,/docs directory.https://github.com/OpenChain-Project/AI-WG/tree/main/docs (accessed: 2026-06-12). — The primary source document for this report.↩

A2. OpenChain Project AI Work Group.AI-WG repository (working group home).https://github.com/OpenChain-Project/AI-WG (accessed: 2026-06-12). — Basis for the guide’s publication context and the working group’s operation.↩

A3. ISO/IEC (2020).ISO/IEC 5230:2020 — Information technology — OpenChain Specification.https://www.iso.org/standard/81039.html (accessed: 2026-06-12, automated verification limited: iso.org blocks bots). — The parent standard from which the guide draws inspiration. Basis for the reference to Section 3.3.2 in the License Obligations (3.5) section.↩

A4. ISO/IEC (2023).ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system.https://www.iso.org/standard/81230.html (accessed: 2026-06-12, automated verification limited: iso.org blocks bots). — The standard the guide’s footnotes repeatedly reference (Annex B, Section 7.3).↩

A5. ISO/IEC (2021).ISO/IEC 5962:2021 — Information technology — SPDX Specification V2.2.1.https://www.iso.org/standard/81870.html (accessed: 2026-06-12, automated verification limited: iso.org blocks bots). — The SBOM format standard referenced directly in the overview.↩

A6. Bradner, S. (1997).RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels. IETF, BCP 14.https://www.ietf.org/rfc/rfc2119.txt (accessed: 2026-06-12). — Source for the MUST/SHOULD/MAY interpretation in Chapter 2’s terms and definitions.↩

A9. OpenChain Project (2025-10-20).Welcoming the OpenChain AI System Bill of Materials Compliance Guide.https://openchainproject.org/news/2025/10/20/welcoming-the-openchain-ai-system-bill-of-materials-compliance-guide (accessed: 2026-06-12). — Primary source for the Version 1 formal publication date (2025-10-20), the document’s nature (a reference guide), and its distribution formats (PDF, Markdown).↩

A10. OpenChain Project (2025-07-07).Public Comment Period Announced: Artificial Intelligence System Bill of Materials – Compliance Management Guide for the Supply Chain.https://openchainproject.org/news/2025/07/07/public-comments-ai-system-bill-of-materials (accessed: 2026-06-12). — Primary confirmation of the six-week public comment period’s opening (2025-07-07) and closing (2025-08-18).↩

A11. OpenChain Project (2025-08-20).Review of Public Comments and Next Steps: Artificial Intelligence System Bill of Materials – Compliance Management Guide for the Supply Chain.https://openchainproject.org/news/2025/08/20/ai-bom-next-steps (accessed: 2026-06-12). — The comment review outcome and the Governing Board’s publication decision process.↩

A12. OpenChain Project.Reference-Material repository — AI-SBOM-Compliance/en (formal edition distribution location).https://github.com/OpenChain-Project/Reference-Material/tree/master/AI-SBOM-Compliance/en (accessed: 2026-06-12). — The actual distribution location of the citable formal edition.↩

A13. OpenChain Project (2023-12-19).OpenChain Welcomes ISO/IEC 18974:2023, The International Standard For Open Source Security Assurance.https://openchainproject.org/news/2023/12/19/openchain-welcomes-iso-iec-18974 (accessed: 2026-06-12). Standard text:https://www.iso.org/standard/86450.html. — Basis for OpenChain’s extension into the security domain (ISO/IEC 18974:2023).↩

A14. OpenChain Project (2020).OpenChain ISO/IEC 5230:2020 Specification (en). GitHub License-Compliance-Specification.https://github.com/OpenChain-Project/License-Compliance-Specification/blob/master/Official/en/ISO-5230-2020/ISO-5230-2020.md (accessed: 2026-06-12). — Primary source for the “Verification Materials + Rationale” structure and the statement that it “focuses on what and why, leaving how and when non-prescriptive.”↩

B. AI BOM Formats

B2. SPDX Project.SPDX 3.0.1 Specification — AI Profile.https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/ (accessed: 2026-06-12). — The primary specification for the concrete data elements that go into an AI SBOM.↩

B5. CycloneDX.Capabilities — Machine Learning Bill of Materials (ML-BOM).https://cyclonedx.org/capabilities/mlbom/ (accessed: 2026-06-12). — The ML-BOM specification. History from its introduction in v1.5 (2023-06) through v1.7 (2025-10, ECMA-424 2nd edition).↩

B6. The Linux Foundation (2024-04-16).SPDX 3.0 Revolutionizes Software Management in Systems with Enhanced Functionality and Streamlined Use Cases (press release, Seattle).https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases (accessed: 2026-06-12). — Primary source for the SPDX 3.0 release date (2024-04-16) and the new AI Profile use cases.↩

B7. OWASP Gen AI Security Project.OWASP AIBOM Generator.https://genai.owasp.org/resource/owasp-aibom-generator/ (accessed: 2026-06-12). — Primary source for the public tool that automatically generates a CycloneDX-format AI SBOM from a Hugging Face model and scores its completeness.↩

B8. cdxgen Project (OWASP CycloneDX).AI/ML-BOM generation (AI_BOM.md). GitHubcdxgen/cdxgen.https://github.com/cdxgen/cdxgen/blob/master/docs/AI_BOM.md (accessed: 2026-06-12). — Primary source for how to use cdxgen’s dedicated AI BOM mode (Hugging Face URL, Modelfile, GGUF input).↩

C. Regulation and Governance

C1. European Parliament and Council (2024).Regulation (EU) 2024/1689 — Artificial Intelligence Act. Official Journal of the EU, 2024/1689, 13.6.2024 (published in the Official Journal 2024-07-12, entered into force 2024-08-01).https://eur-lex.europa.eu/eli/reg/2024/1689/oj (accessed: 2026-06-12). — The EU AI Act text specified in the Governance (3.10) section. Primary regulatory source for the phased application dates of Article 113 and for the transparency and risk management obligations.↩

C4. OECD.Hiroshima AI Process (HAIP) Reporting Framework (transparency.oecd.org).https://transparency.oecd.org/ (accessed: 2026-06-12, automated verification limited: connection refused/bot blocked). — The submission platform for the HAIP corporate reporting framework. Basis for the 1.0 stage.↩

C6. European Commission.AI Act | Shaping Europe’s digital future (Regulatory framework for AI).https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai (accessed: 2026-06-12). — Primary confirmation that GPAI obligations apply from 2025-08-02. Cross-reference, together with the EUR-Lex text (C1), for the application date and scope of obligations.↩

C7. OECD.AI (2026-05-28).OECD launches Hiroshima AI Process Reporting Framework 2.0.https://oecd.ai/en/haip-2-launch (accessed: 2026-06-12). Press release:https://www.oecd.org/en/about/news/press-releases/2026/05/oecd-launches-streamlined-hiroshima-ai-process-reporting-framework-to-help-small-and-medium-sized-enterprises-participate.html (automated verification limited: oecd.org blocks bots). — Basis for the HAIP Reporting Framework 2.0 launch date (2026-05-28, Paris G7 Digital and Technology Ministers’ Meeting), its focus on small and medium-sized enterprises, its role-based structure, participation by more than 50 organizations, and the next review deadline (2026-09-01).↩

D. SBOM Policy Background

D1. NTIA, U.S. Department of Commerce (2021).The Minimum Elements For a Software Bill of Materials (SBOM) (implementing Executive Order 14028 §10(j), 2021-07-12).https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf (accessed: 2026-06-12, automated verification limited: .gov blocks bots). — The SBOM minimum elements policy baseline from which AI SBOM descends.↩

D4. NIST.Software Security in Supply Chains: Software Bill of Materials (SBOM) — Executive Order 14028. Information Technology Laboratory.https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1 (accessed: 2026-06-12). — The primary NIST page that carries Executive Order 14028’s SBOM definition and recommends compliance with SPDX, CycloneDX, and SWID and meeting the NTIA minimum elements.↩

E. Supplementary (Academic/Industry)

E4. Jewitt, J., Li, H., Adams, B., Rajbahadur, G. K., Hassan, A. E. (2025).From Hugging Face to GitHub: Tracing License Drift in the Open-Source AI Ecosystem. arXiv:2509.09873.https://arxiv.org/abs/2509.09873 (accessed: 2026-06-12). — Academic source quantifying license drift (35.5% loss of restrictive clauses in model-to-application transitions, 0.4% preservation of ML-specific obligations).↩

E5. arXiv (2025).New Tools are Needed for Tracking Adherence to AI Model Behavioral Use Clauses. arXiv:2505.22287.https://arxiv.org/abs/2505.22287 (accessed: 2026-06-12). — Notes the lack of tools to track compliance with the behavioral use restrictions in RAIL/OpenRAIL and the Llama Community License.↩

E6. Jin, S. et al. (2025).Building an Open AIBOM Standard in the Wild. arXiv:2510.07070 (accepted at ICSE 2026 SEIP).https://arxiv.org/abs/2510.07070 (accessed: 2026-06-12). — Discusses the OWASP AIBOM project’s standardization approach and the gap in representing AI datasets and training artifacts.↩

E8. JUN Legal (2025-03-18).Responsible AI Licenses (RAIL).https://jun.legal/en/2025/03/18/responsible-ai-licenses-rail-verantwortungsvolle-ki-nutzung-durch-lizenzierung/ (accessed: 2026-06-12). — Industry/legal commentary explaining that RAIL/OpenRAIL and the Llama Community License fail to meet the OSI Open Source Definition because of their behavioral use restrictions.↩