Summary

On July 29, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) and 17 other agencies published a revised set of minimum elements for a Software Bill of Materials (SBOM)[A2]. The document states plainly that it replaces, rather than amends, the baseline established in 2021 by the National Telecommunications and Information Administration (NTIA).

The bar has risen noticeably. The data fields grew from 7 to 17, and six operational practices were specified alongside them. Ten of the elements are entirely new.

Three changes matter most in practice.

• Licensing entered the SBOM minimum baseline for the first time.
• Dependencies must now be recorded in full, down to transitive dependencies, with no depth limit.
• New fields were added to declare the origin and integrity of the SBOM document itself.

The document carries no effective date and no enforcement power. Preparation is still warranted, because national regulations increasingly require SBOMs without enumerating the fields those SBOMs must contain. The practical significance of this document is that it gives procurement contracts a multilateral consensus baseline to cite.

The nature of that preparation is easy to misjudge. Meeting the minimum elements is not a matter of picking a tool. Fewer than half of the 23 elements can be filled by a generation tool on its own. The rest are filled by the build pipeline, the signing infrastructure, and policies the organization decided on in advance.

I also checked how far an actual tool gets. BomLens is an SBOM generation and management tool that SK telecom developed for software supply chain security and released as open source. Assessing all 23 elements with it produced the following:

• The tool fills 11 of the 17 data fields directly with values.
• It inspects supplier-submitted SBOMs against all 23 elements, separating out the 4 that the organization must decide as items for human review.
• The remaining gaps exist not because the tool is deficient, but because those values must be determined by whoever runs it or by the build stage at which it runs.

The assessment screen can be viewed directly in thepublic demo, with nothing to install.

1. What Changed

1.1 The Structure of the Elements

The minimum elements fall into two categories. Seventeen data fields are the values actually carried in the SBOM document; six operational practices govern how an organization handles SBOMs.

Figure 1. The composition of the CISA 2026 SBOM minimum elements(source: 2026 Minimum Elements for a SBOM, 2026-07-29)

SBOM metadata is a category that did not exist in the 2021 edition. Where the earlier baseline asked for little more than an author and a timestamp, the document now requires the SBOM to declare for itself which tool produced it, when, at what stage, and who signed it.

1.2 Three Substantive Changes

Licensing became mandatory. The seven data fields of the 2021 edition did not include licensing, because that document was aimed at security and vulnerability management. The revision adds component licensing as a new element, requiring that it be conveyed in a machine-processable form such as an SPDX license identifier where possible, and that the presence of proprietary license terms be disclosed as well. Territory that belonged to the Open Source Program Office (OSPO) is now part of the SBOM minimum baseline.

The floor on dependency resolution is gone. The Depth element of the 2021 edition required only top-level dependencies. The revision replaces it with a Coverage element that requires all constituent components including transitive dependencies, and states explicitly that recording only to a certain depth is no longer sufficient. The document is candid about why. The 2021 baseline “reflected the capabilities of SBOM tooling at the time rather than the depth of information needed for informed security decisions,” and since tooling has advanced in the interim, the requirement has been raised.

Supplier Name became Component Producer. This is a change of definition, not merely of label. The document states that Supplier Name “proved ambiguous in practice, particularly in relation to software distributors.” The intent is to end the practice of naming redistributors and to point the field at the entity that originally created the software. Where the producer is unclear, as with open source projects, the document requires that the unknown provenance be stated explicitly.

Separately, Software Identification (SWID) tags were dropped from the list of accepted formats. Two remain: SPDX and CycloneDX.

2. What the OSPO Must Decide

The six operational practices are items an organization must answer, not a tool. The document says as much: organizations “should explicitly address these elements in all policies, contracts, and agreements that require or provide SBOMs.”

2.1 How Much to Include

The Coverage element requires all transitive dependencies while permitting the exclusion of non-code files. It adds that security-relevant files, such as configuration files, may be included. Where to draw the line on security relevance is for the organization to decide.

The vulnerability management test offered by the document is a useful criterion: an SBOM recipient should be able to conclude that a newly reported vulnerability does not affect them if the associated component is absent from the list. A scope definition that fails this test does not satisfy the Coverage requirement.

Linking each subcomponent to a separate SBOM is also permitted, but with a condition. The recipient must be able to access every linked SBOM. Providing links without access rights does not meet the requirement.

2.2 When to Regenerate

The Frequency element requires a corresponding SBOM for each software version or update. Every new build or release calls for a new SBOM, and that includes builds where only dependencies changed.

One more obligation attaches here. If errors are found in existing SBOM data, or new facts about a component come to light, a revised edition must be issued. This means an SBOM may need to be reissued without any accompanying release, which in turn requires a way to track where already-distributed SBOMs went.

2.3 How to Record What Is Not Known

Explicit identification of unknowns is a major update. The requirement is specific: when a value is absent, it must be clear whether the information is unknown to the author or whether the author is knowingly withholding it.

The distinction conveys different information to the recipient. Unknown means the supply chain trace broke off at that point; withheld means the supplier has the information and is not providing it. For the latter case, the document requires a process through which recipients can inquire, and adds that an SBOM withholding essential component data may be treated as incomplete.

In practice, the notation convention has to be settled first. Simply leaving a field empty makes the three cases indistinguishable: whether the value does not exist, was never confirmed, or was deliberately not disclosed.

2.4 Which Formats to Accept

The machine-readable data element names SPDX and CycloneDX while directing organizations to accept widely used, interoperable formats. One condition attaches: SBOMs for new software generated with deprecated versions should not be accepted.

That condition creates a second acceptance criterion. Format version matters as much as format name, and the new SBOM data format name and version elements provide the basis for that judgment.

2.5 What to Put in Contracts

Translated into contract language, the items above come out as follows.

• The required format and minimum version
• The coverage scope, including transitive dependencies
• The obligation to supply an SBOM with each release, and to supply a revision when errors are found
• Distinct notation for unknown versus withheld, and an inquiry process for withheld items

The three actions the document recommends to organizations point the same way: require SBOMs that satisfy the updated minimum elements, use tooling to generate, collect, and analyze SBOM data, and generate SBOMs that satisfy the minimum elements themselves.

3. Who Fills Each Element

Sorting the 23 elements by who fills them clarifies what preparation actually involves.

Figure 2. The four domains that fill the 23 minimum elements(source: compiled from the element definitions in the original document)

What a generation tool can handle alone sits on the component data side. The rest must be filled from outside the tool.

Generation context must be recorded inside the build pipeline to be accurate. An SBOM built from source corresponds to “pre-build” and one built from binary analysis to “post-build” — a value determined by when the scan runs, not by what it scans.

Component hashes require an executable artifact to compute. At source-scan time that artifact does not yet exist, making it inherently impossible, and the document itself prescribes an unknown marking for this case. Requiring hashes means generating or updating the SBOM at a post-build stage.

Author signatures presuppose key management. The document directs organizations to use existing software signing infrastructure and key management, which falls outside the scope of an SBOM tool.

SBOM Author is a value the tool cannot know. Since the definition is the entity operating the tool, whoever runs it has to supply it.

3.1 Which Formats Carry the New Elements

Formats differ in how far they carry the 10 new fields, which makes the choice of format itself a practical decision[C3].

Table 1. How each format can express the new elements(source: RunSafe Security field mapping analysis, 2026)

CycloneDX has the advantage on the new metadata. Generation context and signatures exist as native fields, and the lifecycle phase vocabulary the original document uses as an example maps across directly.

Conversely, SPDX offers the better mechanism for marking unknowns. Its standardNOASSERTION marker distinguishes “no value” from “not determined,” whereas CycloneDX has no marker at that level, requiring a separate convention using properties or annotations. And marking unknowns is precisely one of the requirements this revision strengthened.

The judgment at this point is as follows. The combination that carries the minimum elements most completely is CycloneDX 1.6, provided the organization establishes its own convention for marking unknowns. Organizations using SPDX as their primary format have no place in 2.3 for generation context or signatures, which makes this the moment to consider migrating to 3.0.

4. Relationship to Regulation

The minimum elements carry no legal force in themselves. The disclaimer states that the publication “is not intended as compliance, regulatory, or legal advice.”

Its real influence comes through citation. The European Union Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to provide an SBOM as part of the technical documentation, but does not enumerate the fields in its text[A5]. Germany’s BSI TR-03183-2 filled that gap with concrete technical requirements, and India’s CERT-In and Japan’s Ministry of Economy, Trade and Industry have issued guidance of their own. The minimum elements are the baseline these all reference in common.

One caution applies. Although the European Commission’s Directorate-General for Communications Networks, Content and Technology (DG CONNECT) contributed to the drafting, a footnote states that the document does not interpret European Union law, does not bind the Commission, and that not all of its elements reflect Union law. It cannot be used as-is to demonstrate Cyber Resilience Act compliance.

There is also a terminological trap. A footnote in the original explicitly warns against confusing the “producer” of Component Producer with the “manufacturer” of the Cyber Resilience Act. Every manufacturer is a producer, but not every producer is a manufacturer. Documents that address both regimes need to keep the terms distinct.

From Korea, two organizations participated as co-authors: the National Cyber Security Center under the National Intelligence Service, and the Korea Internet & Security Agency. That participation gives domestic procurement and internal policy a basis for citing this document. Because the international common baseline was updated immediately after the government’s joint Software Supply Chain Security Roadmap was announced in June 2026, domestic policy now has a reference to draw on when it comes to specifying required fields.

Organizations working with AI systems should note the ordering. The original document introduces no AI-specific elements, deferring them to the G7 joint guidance[A10]. The two documents are hierarchical: fill this general software baseline first, then add the AI-specific elements.

5. How Far Do Actual Tools Get Today

Reading a baseline and confirming that a tool actually meets it are separate exercises. Even when a format has a place for a value, the field stays empty if the tool does not put one there.

I assessed all 23 elements using BomLens, the SBOM generation and management tool that SK telecom developed for software supply chain security and released as open source. The basis was actual scan output and source code rather than estimation[D1].

5.1 What the Tool Fills with Values

The tool fills 11 of the 17 data fields directly.

• SBOM metadata: data format name and version, generation context, timestamp, tool name, SBOM version
• Component data: name, version, identifier, license, dependency relationships

Three of these are filled in ways that bear directly on the minimum element requirements.

• Generation context is determined automatically from the input type. Source scans are recorded aspre-build and container and binary scans aspost-build, so the user never selects the value.
• Licensing is filled for 98.4% of components on the source path and 94.7% on the container path. The source side reads from package manifests, the container side from the operating system package database.
• The tool name records both BomLens itself and its underlying generators. The minimum elements ask for the tools that generated or modified the SBOM, so both are retained.

Among the six operational practices, it satisfies machine-readability and distribution and delivery. It emits CycloneDX 1.6 as its default format and supports conversion to SPDX 2.3, covering both formats the minimum elements designate.

5.2 What the Tool Cannot Fill

The remaining items are empty not because the tool falls short, but because of the structure described in section 3.

• SBOM author and author signature: the entity running the tool must supply the value. The author is passed via--sbom-author, and signing is a separate option that uses cosign.
• Component hash: at source-scan time no executable artifact exists to hash. On paths where an artifact does exist, such as containers and firmware, the scan target itself is hashed.
• Component producer: the package metadata must carry producer information for this to be filled. Coverage is 60.9% on the source path and 94.7% on the container path.

How the absence of a value is handled matters from the minimum elements perspective. When no author is specified, this tool does not writeunknown; it leaves the field empty and adds a document-level declaration that empty fields were not determined by the author. Because the minimum elements define the author as the entity operating the tool, and that entity knows who it is, a tool writingunknown would not be marking an unknown but making a false statement. Hashes follow the same principle: no value is invented.

5.3 Assessing Received SBOMs Against the Minimum Elements

The tool can also inspect supplier-submitted SBOMs against all 23 elements. Results come out in three branches.

Figure 3. The conformance assessment screen. All 23 elements are assessed, with the 4 the tool cannot judge separated out for human review(BomLens 1.10.3 output, 2026-08-09)

• Met, 13 — the 11 data fields plus 2 operational practices.
• Not met, 6 — the items covered in section 5.2.
• Human review, 4 — Coverage, Accommodation of Updates to SBOM Data, Distribution and Delivery, and Frequency. These are decided by the organization, so the tool passes them to a person rather than judging them.

Not treating what it cannot judge as a pass is what makes this useful in practice. The four items marked for human review are the same organizational decisions covered in section 2.

The same screen can be opened directly in thepublic demo. It runs in a browser with nothing to install, and each element carries a note on what is missing and how to fill it. Note that the demo shows the result of inspecting a supplier-submitted SBOM, so its subject differs from the figure above.

5.4 What Remains

Some gaps remain before the minimum elements are fully met.

• The tool version is recorded as an image tag rather than a release number. The minimum elements call for a value that identifies a specific delivery of code.
• The SBOM version stays fixed at 1 across regenerations and cannot express revision relationships. This connects directly to the accommodation of updates element, but a locally running tool cannot know where its previous output went, which makes user-specified versioning the realistic alternative.

6. Conclusion

What the revised minimum elements demand is not more fields but a different kind of preparation.

With licensing in the minimum baseline, the SBOM is no longer a document belonging to the security team alone. Filling in license identifiers in machine-processable form, disclosing the presence of proprietary terms, and stating plainly when something is not known — this is how an OSPO already works. What changed is that the result now has to leave the organization in a standard format.

Much of the preparation has to be finished before a tool is selected. Four items are for the organization to decide.

• How much to include
• When to regenerate
• How to mark what is not known
• Which formats and versions to accept

Adopt a tool without settling these, and whatever defaults the tool produces become the organization’s policy.

It is equally necessary to separate what can be demanded of a tool from what cannot. A source-scanning tool cannot be asked for the hash of an executable artifact, and no tool can decide an organization’s name on its behalf. Demand that unfillable values be filled and the tool will invent plausible ones, which is the direction the minimum elements prohibit.

Checking what your current tool fills and what it leaves empty is worth doing once. Format support and field satisfaction are different questions, and the gap between them only shows when you open the output yourself. If there is no obvious tool at hand to check, BomLens from section 5 is a starting point. It is open source and free to download, and it shows both how far a generated SBOM meets the 23 elements and whether a supplier-submitted SBOM meets the baseline, on the same screen.

References

A2. Cybersecurity and Infrastructure Security Agency and 17 other agencies (2026).2026 Minimum Elements for a Software Bill of Materials (SBOM). v2.1, published July 29, 2026, TLP:CLEAR.https://www.cisa.gov/sites/default/files/2026-07/2026_cisa_sbom_minimum_elements_508c.pdf.

A5. European Parliament and Council (2024).Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal of the European Union, October 23, 2024.https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402847.

A10. CISA and G7 partners (2026).Software Bill of Materials for AI – Minimum Elements. May 2026. — Covered in detail in theG7 SBOM for AI Minimum Elements report.

A1. National Telecommunications and Information Administration (2021).The Minimum Elements For a Software Bill of Materials (SBOM). Published July 12, 2021.https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom.

A3. Federal Register (2025).Request for Comment on 2025 Minimum Elements for a Software Bill of Materials. Published August 22, 2025; comment period closed October 3, 2025.https://www.federalregister.gov/documents/2025/08/22/2025-16147/request-for-comment-on-2025-minimum-elements-for-a-software-bill-of-materials.

B1. SPDX.The System Package Data Exchange.https://spdx.dev/. ISO/IEC 5962:2021.

B2. CycloneDX.https://cyclonedx.org/. Ecma International,ECMA-424: CycloneDX Bill of Materials Specification, December 2025.

C3. RunSafe Security (2026).Mapping CISA’s 2026 SBOM Minimum Elements to CycloneDX and SPDX.https://runsafesecurity.com/blog/sbom-minimum-elements-cyclonedx-spdx/. — The basis for Table 1. The per-format field mapping is taken from this analysis and was not verified directly against the specifications.

D1. BomLens. An SBOM generation and management tool developed and released by SK telecom for software supply chain security, Apache-2.0.https://github.com/sktelecom/bomlens. The coverage assessment in section 5 was determined from actual scan output and source code using version 1.10.3 of this tool.

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.

A Software Bill of Materials (SBOM) is a formal record of what components make up a piece of software and how those components connect within the supply chain. A US executive order compares it to the ingredient list on food packaging. Just as an ingredient list is the starting point for responding to allergies, an SBOM is the data layer on which vulnerability response, license management, and asset management all rest. An SBOM is not a security tool in itself, but without one, an organization cannot immediately answer the question, “Where in our product is this library used?”

This guide covers that data layer from beginning to end. Drawing on primary sources, it explains why SBOM has moved to the forefront of regulation and procurement, what standards and identifiers underpin it, in what order organizations adopt it and with what tools they automate it, how they manage vulnerabilities and licenses, and how they share it securely across the supply chain.

Intended Audience

• Security, development, procurement, and legal staff at organizations that develop or procure software
• Practitioners who must respond to the EU Cyber Resilience Act (CRA) or US federal procurement requirements
• Teams seeking to establish supply chain transparency and open source license compliance systems

Guide Structure

The guide is divided into eight sections. The earlier sections cover concepts, standards, and regulation, while the later sections cover the practicalities of adoption and operation. You can read only the sections you need.

Quick Starting Points

If you already understand SBOM and are looking for where to start, see4. Adoption Roadmap and8. Recommendations and Checklist first. If you are deciding which format and tools to use,2. Standards and Formats and5. Tools and Automation are good starting points. If your goal is regulatory compliance, check the jurisdiction-specific obligations in3. Regulatory Trends.

Sources and Editorial Basis

This guide is not a translation of any single document; it is a reconstruction that synthesizes current primary sources. It draws on the National Telecommunications and Information Administration (NTIA)’s 2021 minimum elements and its update by the Cybersecurity and Infrastructure Security Agency (CISA) — the 2024Framing Software Component Transparency, Third Edition, and the 2025 draft revision of the minimum elements — as well as the SPDX and CycloneDX standard specifications, the EU Cyber Resilience Act (Regulation (EU) 2024/2847), and the supply chain security guidelines of India’s CERT-In and Korea. The first edition began as a translation of CERT-In’s SBOM technical guidelines; the current edition updates that framework with the sources above and broadens it to a general practitioner’s perspective.

Every factual claim is cited to a primary source, and the materials cited were accessed on June 14, 2026.

Author :Haksung Jang

1. Clause Overview

An AI SBOM (AI System Bill of Materials) is a list capturing the elements that make up an AI system and the information about them. Where a traditional SBOM records software components, an AI SBOM adds models, weights, datasets, and hyperparameters on top. 3.9 requires a procedure for generating and managing the AI SBOM.

The format is left open. The specification states that SPDX, CycloneDX, or any other format is acceptable. There is, however, one obligation: the AI SBOM shall account for inbound materials from third parties. If pre-trained models and datasets brought in from outside are left out, the basis for tracking license obligations (3.5) and transparency obligations disappears.

The AI SBOM area is where the line “generation is automated by tools, but accuracy and compliance judgment are filled by people” is sharpest. This page walks through the procedure along that line.

2. Activities to Perform

• Establish a procedure for identifying, tracking, reviewing, approving, and archiving the components of an AI system (models, datasets, etc.).
• Decide on an AI SBOM format (SPDX 3.0 AI Profile or CycloneDX ML-BOM recommended).([Guide Recommendation])
• Ensure models and datasets brought in from third parties are always included in the AI SBOM.
• Wire a generation tool into CI/CD to regenerate the AI SBOM repeatedly.([Guide Recommendation])
• Have a person review whether the license and provenance fields of the generated AI SBOM are accurate.([Guide Recommendation])
• Retain records (generation history, approval history) demonstrating that the procedure was followed.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.9.1 AI SBOM Management Procedure (Identification, Tracking, Review, Approval, Archiving)

How to Comply

Design the AI SBOM procedure around four stages: generation, review, approval, and archiving. Automate the generation stage with tools, and leave the review and approval stages to people. Even when a tool copies a license field straight from a model card, it cannot judge whether that license actually fits the use case, or whether something is missing or misstated.

The figure below shows the flow from AI SBOM generation to archiving.

Figure 1. Procedure from AI SBOM generation to archiving

Tool Mapping

Below are open source tools usable at each stage. “Automation level” indicates how far a tool handles that task on its own.

Installation, usage, and execution screens for each tool are covered in detail in theTools section (OWASP AIBOM Generator,cdxgen,Model/Container Scanners).

The command to generate an AI BOM with cdxgen is as follows. You can pass a Hugging Face model URL and purl, a Modelfile, or a GGUF artifact directly (cdxgen AI-BOM docs).

# Generate an AI BOM from the AI project directorycdxgen -t ai -o aibom.json .# Generate including AI/ML metadata (formulation)cdxgen -t ai --include-formulation -o aibom.json .

The OWASP AIBOM Generator takes a Hugging Face model as input, builds a CycloneDX-format AIBOM, and scores its completeness. It is maintained by the OWASP Gen AI Security Project and is also available as a Hugging Face Space (OWASP AIBOM Generator).

Hands-On — Generating with cdxgen

This is the result of actually running cdxgen against a summarization app (depending ontransformers andtorch) that loads a pre-trained model (facebook/bart-large-cnn). The tool automatically identifies 5 dependencies and produces a CycloneDX 1.7-format BOM.

$ cdxgen -t python --include-formulation -o aibom.json .CycloneDX Generator 12.5.1 (Node.js)Generated components — 5 items (CycloneDX 1.7): transformers 4.44.2 pkg:pypi/transformers@4.44.2 license: empty torch 2.4.0 pkg:pypi/torch@2.4.0 license: empty numpy 1.26.4 pkg:pypi/numpy@1.26.4 license: empty tokenizers 0.19.1 pkg:pypi/tokenizers@0.19.1 license: empty huggingface-hub 0.24.6 pkg:pypi/huggingface-hub@0.24.6 license: empty

One component from the generated BOM looks like this. The identification evidence is filled in, but thelicenses field is empty.

{"name":"transformers","version":"4.44.2","purl":"pkg:pypi/transformers@4.44.2","type":"library","evidence":{"identity":[{"field":"purl","confidence":0.5,"methods":[{"technique":"manifest-analysis","value":"requirements.txt"}]}]}}

Figure 2. cdxgen 12.5.1 execution output(run on 2026-06-13,-t python --include-formulation)

Format Sample (CycloneDX ML-BOM)

Below is a shortened example of the model component structure in a CycloneDX 1.6 ML-BOM. The key structure follows themachine-learning-model component andmodelCard in theofficial CycloneDX spec. If the license is non-standard (has no SPDX ID), state it withname.

{"bomFormat":"CycloneDX","specVersion":"1.6","components":[{"bom-ref":"model-llama31-8b","type":"machine-learning-model","group":"meta-llama","name":"Llama-3.1-8B","version":"1.0","licenses":[{"license":{"name":"Llama 3.1 Community License"}}],"modelCard":{"modelParameters":{"task":"text-generation","architectureFamily":"llama","datasets":[{"type":"dataset","name":"Public pretraining corpus","classification":"public"}]},"considerations":{"useCases":["Internal document summarization"],"technicalLimitations":["Potential for hallucination","Performance variance in Korean"]}}}]}

If you use SPDX 3.0, the AI Profile and Dataset Profile express the same information (SPDX 3.0 AI Profile). The concrete fields of each format and the technical details of generation tools are covered in theISO/IEC 42001 Guide — AI SBOM.

Considerations

• Reflect inbound materials (specification obligation): Set up a procedure that generates an SBOM entry at intake time so that models and datasets brought in from outside are never missing from the AI SBOM. This is ashall-level obligation.
• Generation by tool, review by people: Generation tools copy the license written on the model card as-is. Because model cards themselves commonly have missing or incorrect license information, have a person check the license and provenance fields of the generated AI SBOM against the original source.
• Format consistency: Pick either SPDX or CycloneDX as the organization’s default format and operate tools and repositories around it consistently. Both formats treat models and datasets as first-class components.
• CI/CD integration: The AI SBOM is not a one-time deliverable. Wire it into the pipeline so it is regenerated whenever a model or dataset changes.

3.9.2 Records Demonstrating Procedure Compliance

How to Comply

Verification material 3.9.2 is the record showing the procedure was actually followed. Alongside the AI SBOM file itself, keep a history of who generated, reviewed, and approved it and when. If it is generated automatically in CI/CD, the build logs and the generated SBOM artifact become the record, and the upload history to a management tool such as Dependency-Track also serves as evidence.

Considerations

• Retain generation history: Keep the AI SBOM from each point in time for every version of the supplied AI system to maintain traceability.
• Approval record: Record who reviewed and approved it. This connects to the lifecycle review inGovernance (3.10).

5. References

• License obligation review procedure:3.5 License Obligations
• Technical details of AI SBOM formats and generation tools:ISO/IEC 42001 Guide — AI SBOM
• SBOM management tools:Dependency-Track,cdxgen + Dependency-Track integration
• Governance and lifecycle review:3.10 Governance

Overview

cdxgen is the official SBOM generator of the OWASP CycloneDX project. It supports more than 20 languages and package managers, and the latest version offers a dedicated AI BOM mode. It automatically identifies the dependencies of AI applications (PyTorch, Transformers, and so on) and integrates well with CI/CD pipelines.

From an AI SBOM standpoint, cdxgen’s strength is speed and automation. Its weakness is that it does not fill in license information in a default run. This trait shows up in the execution result below. Where OWASP AIBOM Generator centers on model card metadata, cdxgen centers on code and dependencies. Using both together covers both models and dependencies.

Key Features

• Identifies dependencies from source code and container images to generate a CycloneDX SBOM.
• Includes AI/ML metadata (formulation) with AI BOM mode (-t ai).
• Takes Hugging Face model URLs, Modelfiles, and GGUF artifacts directly as input.
• Automatically submits SBOMs to a Dependency-Track server for continuous management.

Installation

# One-off run (requires Node.js)npx @cyclonedx/cdxgen@latest --version# Global installnpm install -g @cyclonedx/cdxgen

Usage — Generating an AI BOM

Run in AI BOM mode from the AI project directory.

# Generate an AI BOMcdxgen -t ai -o aibom.json .# Generate including AI/ML metadata (formulation)cdxgen -t ai --include-formulation -o aibom.json .

Below is the actual result of running cdxgen against a summarization app (transformers,torch dependencies) that loads a pretrained model (facebook/bart-large-cnn). It automatically identifies 5 dependencies and produces a CycloneDX 1.7 BOM.

$ cdxgen -t python --include-formulation -o aibom.json .CycloneDX Generator 12.5.1 (Node.js)Generated components — 5 entries (CycloneDX 1.7): transformers 4.44.2 pkg:pypi/transformers@4.44.2 license: empty torch 2.4.0 pkg:pypi/torch@2.4.0 license: empty numpy 1.26.4 pkg:pypi/numpy@1.26.4 license: empty tokenizers 0.19.1 pkg:pypi/tokenizers@0.19.1 license: empty huggingface-hub 0.24.6 pkg:pypi/huggingface-hub@0.24.6 license: empty

Figure 1. cdxgen execution output(cdxgen 12.5.1, run 2026-06-13)

One of the generated components looks like this. The identification evidence is filled in, but thelicenses field is empty.

{"name":"transformers","version":"4.44.2","purl":"pkg:pypi/transformers@4.44.2","type":"library","evidence":{"identity":[{"field":"purl","confidence":0.5,"methods":[{"technique":"manifest-analysis","value":"requirements.txt"}]}]}}

What the Execution Result Shows

See Also

• AI SBOM generation and management procedure:3.9 AI SBOM
• Generator centered on model metadata:OWASP AIBOM Generator
• SBOM management:Dependency-Track,cdxgen + Dependency-Track integration
• Official:cdxgen AI-BOM documentation

Since an SBOM requires machine readability, a standard format is necessary. Among the three formats specified by the US NTIA minimum elements, SPDX and CycloneDX split practical use between them. The third, the SWID tag, is used mainly in asset management; its role as an identifier is covered inIdentifiers and Licenses.

SPDX

SPDX (System Package Data Exchange) is a project under the Linux Foundation. Version 2.2.1 became an international standard as ISO/IEC 5962:2021 in August 2021. It is worth noting that the current ISO standard refers strictly to version 2.2.1.

The Linux Foundation released SPDX 3.0 on April 16, 2024, introducing a structure of purpose-specific profiles. The approach layers Security, Build, Dataset, and AI profiles on top of a core model. The AI profile carries model training and characterization information, the Dataset profile carries data provenance and licensing, and the Security profile carries vulnerability identification, severity, exploitability, and mitigation plans. A patch release, 3.0.1, followed in December of the same year. Whether SPDX 3.x is being re-standardized with ISO had not been confirmed as of June 2026.

CycloneDX

CycloneDX is a full-stack BOM standard that originated at OWASP (Open Worldwide Application Security Project). Its distinguishing feature is native support for Vulnerability Exploitability eXchange (VEX) within the format itself. International standardization proceeded through Ecma International’s technical committee TC54. Version 1.6 was published as ECMA-424 1st edition in June 2024, adding a Cryptographic Bill of Materials (CBOM) and CycloneDX Attestations, and v1.7 was announced in October 2025 and standardized as ECMA-424 2nd edition in December 2025. v1.7 added post-quantum cryptography readiness, structured citations, and support for patent objects.

CycloneDX can express software (SBOM), hardware (HBOM), services (SaaSBOM), and machine learning models (ML-BOM) all within a single format.

Comparing the Two Formats

Table 1. Comparison of the two major SBOM standard formats(source: ISO/IEC 5962:2021, Linux Foundation 2024, Ecma International ECMA-424. Retrieved 2026-06-14)

The two standards differ in design philosophy. SPDX extends its scope of application through profiles, while CycloneDX expresses it through component types and auxiliary objects. Both, however, target the same problem in that they carry component identification, licensing, and dependency relationships. Whichever you choose, conversion tools exist between the two formats, so you can choose based on the format your trading partners require and the format your own tool chain supports well. If license compliance is the focus, SPDX is the familiar starting point; if vulnerability operations is the focus, CycloneDX is.

Next, we look at theminimum elements that define what a format must contain, andidentifiers and licenses for consistently pointing to components.

Sources

ISO/IEC (2021).ISO/IEC 5962:2021 — SPDX Specification V2.2.1. The Linux Foundation (2024).SPDX 3.0 Release.https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases. Ecma International.ECMA-424 — CycloneDX Bill of Materials Specification.https://ecma-international.org/publications-and-standards/standards/ecma-424/. CycloneDX (2025).CycloneDX v1.7 Released.https://cyclonedx.org/news/cyclonedx-v1.7-released/. (All retrieved: 2026-06-14)

Overview

OWASP AIBOM Generator is an open source tool that takes a Hugging Face model ID as input, fetches model card metadata, and generates an AI SBOM in CycloneDX format. It is maintained by the OWASP Gen AI Security Project, and its distinguishing feature is scoring how complete the generated BOM is.

Where cdxgen identifies dependencies quickly but leaves the license fields empty, this tool fills in the license, author, and external references recorded in the model card. It works well as a starting point for the license review required by3.5 License Obligations.

Key Features

• Fetches metadata from Hugging Face models and generates an AIBOM in both CycloneDX 1.6 and 1.7 format.
• Evaluates the completeness of the generated BOM with a score (0–100) and a profile, broken down section by section.
• Displays model information, the model card, license, and external references in a human-readable view.
• Available both as a web UI and a command-line interface (CLI).

Usage A — Web UI

The simplest approach: just enter a model ID in the browser. Use the Hugging Face Space provided by the OWASP Gen AI Security Project, or clone the repository and run it locally.

First, enter a Hugging Face model ID (e.g.,facebook/bart-large-cnn) on the input screen and click generate.

Figure 1. OWASP AIBOM Generator input screen(GenAI Security Project, captured 2026-06-13)

Once generation finishes, the result screen shows an AIBOM summary, the completeness assessment, download buttons (CycloneDX 1.6 and 1.7), AI model information, and the model card. The completeness assessment at the top of the screen shows at a glance whether the BOM has the minimum fields needed for identification.

Figure 2. Generation result screen — model information, license (MIT), completeness assessment (Basic)(captured 2026-06-13)

The result screen offers a Human-Friendly View along with a field checklist, a score report, and a JSON view tab. Check the items needed for license obligation review and AI SBOM retention directly on screen, and download the CycloneDX file.

Usage B — Command Line (CLI)

The CLI is convenient for embedding in CI/CD or batch-processing multiple models. After installation, pass the model ID as an argument.

# Install (a Python virtual environment is recommended)pip install"git+https://github.com/GenAI-Security-Project/aibom-generator"# Generate an AIBOM from a model IDaibom facebook/bart-large-cnn -o aibom.json

Below is the actual execution result. It generates CycloneDX 1.6 and 1.7, passes schema validation, and shows the completeness score broken down by section.

$ aibom facebook/bart-large-cnn -o aibom.json✅ Successfully generated CycloneDX 1.6 SBOM — Schema Validation (1.6): Valid✅ Successfully generated CycloneDX 1.7 SBOM — Schema Validation (1.7): Valid📊 Completeness Score: 58.7/100 Profile: Basic - Required Fields: 20/20 - Metadata: 8/20 - Component Basic: 17.1/20 - Component Model Card: 6.7/30 - External References: 10/10

Figure 3. CLI execution output(aibom CLI, model facebook/bart-large-cnn, run 2026-06-13)

The model component in the generated BOM has its license and model card filled in. Unlike cdxgen’s output, thelicenses field is not empty.

{"type":"machine-learning-model","name":"bart-large-cnn","purl":"pkg:huggingface/facebook/bart-large-cnn","licenses":[{"license":{"id":"MIT"}}],"authors":[{"name":"facebook"}],"modelCard":{"modelParameters":{},"considerations":{}}}

What the Execution Result Shows

See Also

• AI SBOM generation and management procedure:3.9 AI SBOM
• License obligation review:3.5 License Obligations
• Another generation tool:cdxgen
• Official:OWASP AIBOM Generator