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.

1. Introduction to SPDX 3.0

SPDX (Software Package Data Exchange) is an open standard for communicating software component, license, copyright, and security information in a standardized way. SPDX 3.0 is the latest version of this standard, released in April 2024, and is a major update that significantly improves the transparency and security of the software supply chain[2].

Definition and Purpose of SPDX

SPDX is a Linux Foundation project that provides a standard format for sharing important information related to software packages. Its main purposes are as follows:

• Providing transparency of software components
• Improving license compliance
• Supporting security vulnerability management
• Enhancing the reliability of the software supply chain

Key Changes in SPDX 3.0

SPDX 3.0 brings significant changes compared to previous versions:

1. Modular structure: SPDX 3.0 consists of a core model and multiple profiles, allowing it to flexibly address a variety of use cases.
2. Improved extensibility: The new version makes it easy to add custom fields and relationships, enabling it to accommodate future requirements.
3. Support for various profiles: It provides various profiles such as Software, Security, License, Build, and AI/ML to meet the requirements of specific domains.
4. Enhanced data model: It can express relationships between entities more clearly, allowing complex software structures to be described more accurately.

Significance of SPDX 3.0

SPDX 3.0 is important for enterprise open source management for the following reasons:

1. Standardization of SBOM generation: It provides a standard format for generating a Software Bill of Materials (SBOM), facilitating information exchange between organizations.
2. Support for regulatory compliance: It meets the SBOM minimum requirements of the US NTIA and complies with various international standards and regulations.
3. Enhanced security: It improves vulnerability management through integration with CVE information and strengthens software supply chain security.
4. Global standardization: It has been adopted as ISO/IEC 5962:2021, becoming an internationally recognized standard[2].

SPDX 3.0 is a powerful tool that greatly improves transparency, security, and compliance throughout the software development and distribution process. By understanding and applying this standard, enterprise open source managers can modernize their organization’s software management processes and reduce risk.

Citations:
[1]https://fossa.com/blog/understanding-using-spdx-license-identifiers-license-expressions/
[2]https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[3]https://fossa.com/learn/spdx
[4]https://fossa.com/blog/sbom-examples-explained/
[5]https://ossna2023.sched.com
[6]https://ossna2023.sched.com/list/descriptions/
[7]https://fossa.com/blog/spdx-3-0/

2. Key Features of SPDX 3.0

SPDX 3.0 is the latest version of software package data exchange, offering significantly improved features compared to previous versions. The key features are as follows:

Modular Structure

SPDX 3.0 introduces a modular structure that greatly improves flexibility and extensibility[1][5]. This structure consists of the following elements:

• Core Model: Defines the core elements that form the basis of every SPDX document.
• Profiles: Provide additional information and functionality tailored to specific use cases.

This modular approach allows users to selectively use only the information they need, reducing complexity and increasing efficiency.

Improved Extensibility

SPDX 3.0 is designed to make it easy to add custom fields and relationships[5]. This provides the following benefits:

• Ability to respond quickly to new technologies and requirements
• Ability to easily incorporate industry-specific requirements
• Ability to flexibly adapt to future changes in the software ecosystem

Support for Various Use Cases

SPDX 3.0 supports various use cases through six main profiles[7]:

1. Security Profile: Includes vulnerability information and security-related metadata
2. License Profile: Provides detailed license information and compliance data
3. AI Profile: Includes information related to AI model training and characterization
4. Dataset Profile: Provides information on dataset provenance and characteristics
5. Software Packaging Profile: Includes package structure and dependency information
6. Build Process Profile: Provides detailed information about the software build process

These profiles help software engineers, security experts, and legal and compliance professionals use SPDX more easily[7].

Enhanced Data Model

SPDX 3.0 provides an enhanced data model that can express relationships between entities more clearly[1]. This enables:

• More accurate description of complex software structures
• Clearer expression of dependencies between software components
• More granular linking of security and license information

Compliance with International Standards

SPDX 3.0 complies with the ISO/IEC 5962:2021 standard, which has significant implications for global software supply chain management[5][6]. This enables:

• Generation of SBOMs in an internationally recognized format
• Compliance with various regulatory requirements (e.g., US government EO 14028, EU Cyber Resilience Act)
• Improved consistency and reliability of software information exchange between organizations

These key features of SPDX 3.0 greatly improve the transparency, security, and compliance of the software supply chain, and play an important role in meeting modern software development and management requirements.

Citations:
[1]https://scribesecurity.com/ko/blog/spdx-vs-cyclonedx-sbom-formats-compared/
[2]https://github.com/spdx/spdx-3-model/releases
[3]https://olis.or.kr/license/licenseSPDX.do?mapcode=010107
[4]https://ettrends.etri.re.kr/ettrends/203/0905203008/0905203008.html
[5]https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[6]https://www.prnewswire.com/news-releases/spdx-3-0-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases-302118321.html
[7]https://www.gttkorea.com/news/articleView.html?idxno=5131

3. SPDX 3.0 Profiles

The concept of profiles introduced in SPDX 3.0 is a key feature that enables SPDX data to be organized and managed according to various use cases. Each profile defines the information and structure required for a specific domain or use case.

Core Profile

The Core Profile defines the core elements that form the basis of every SPDX document.

• Key components:
  • Element: The base class for all SPDX objects
  • Artifact: A class representing a software component
  • Agent: A class representing a person, organization, tool, etc.
  • Relationship: A class defining relationships between entities
• Purpose: Provides the basic structure and information commonly used by all other profiles.
• Example use: Every SPDX document is built on the Core Profile, with information from other profiles added on top of it.

Software Profile

The Software Profile provides detailed information related to software packages.

• Key components:
  • Package: Information about a software package
  • File: Information about an individual file
  • Snippet: Information about a portion of a file
• Purpose: Describes the structure, components, and metadata of software in detail.
• Example use: Used when documenting the structure and components of an open source library.

Security Profile

The Security Profile covers security-related information about software.

• Key components:
  • Vulnerability: Vulnerability information
  • Assessment: Vulnerability assessment information
• Purpose: Provides information on software security vulnerabilities and related assessments.
• Example use: Used when including Common Vulnerabilities and Exposures (CVE) information in an SPDX document.

License Profile

The License Profile covers software license-related information in detail.

• Key components:
  • License: License information
  • LicenseExpression: Complex license expressions
• Purpose: Describes software license information accurately and in detail.
• Example use: Used when documenting the license information of open source software.

Build Profile

The Build Profile provides information about the software build process.

• Key components:
  • BuildStep: Build step information
  • BuildTool: Build tool information
• Purpose: Provides detailed information about how software is compiled and packaged.
• Example use: Used when documenting the build process of a CI/CD pipeline.

AI/ML Profile

The AI/ML Profile covers information specific to artificial intelligence and machine learning models.

• Key components:
  • AIModel: AI model information
  • Dataset: Training dataset information
• Purpose: Describes the characteristics, training data, performance metrics, and other aspects of AI/ML models.
• Example use: Used when documenting the structure and training dataset of a deep learning model.

Each profile reflects the modular structure of SPDX 3.0, and users can select the appropriate profile as needed to generate SPDX documents. This allows various aspects of the software supply chain to be documented and managed effectively.

Citations:
[1]https://spdx.dev/leveraging-profiles-for-license-compliance-insights-from-spdx-mini-summit/
[2]https://spdx.dev/providing-transparency-at-software-developments-core-process-build-time/
[3]https://spdx.github.io/spdx-spec/v2.3/SPDX-license-list/
[4]https://spdx.dev/capturing-software-vulnerability-data-in-spdx-3-0/
[5]https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[6]https://spdx.dev/understanding-spdx-profiles/
[7]https://github.com/spdx/spdx-3-model/actions
[8]https://spdx.github.io/spdx-spec/v3.0/model/AI/AI/

4. SPDX 3.0 Data Model

The data model of SPDX 3.0 is designed to be more flexible and extensible than previous versions. This model better reflects the complexity of the software supply chain and supports a variety of use cases.

Key Entities and Relationships

1. Element
   • The base class for all major objects in SPDX 3.0.
   • Every Element has a unique SPDX ID.
2. Artifact
   • Represents a software component (e.g., package, file, snippet).
   • Includes attributes such as name, version, and supplier.
3. Agent
   • Represents an entity involved in creating the SPDX document, such as a person, organization, or tool.
4. Relationship
   • Defines relationships between entities (e.g., dependency, containment).
   • Specifies the source, target, and relationship type.
5. LifecycleScopedRelationship
   • Represents a relationship specific to a particular software lifecycle stage.
6. Annotation
   • Provides additional information or comments about an entity.

Identifier Scheme

SPDX 3.0 introduces a more robust and flexible identifier scheme:

• SPDX ID: Provides a unique identifier for every Element.
• External identifiers: Can reference identifiers from other systems (e.g., CVE, PURL).
• Namespaces: Clarify the scope of identifiers and prevent collisions.

Metadata Management

1. CreationInfo
   • Includes metadata about the SPDX document itself.
   • Provides information such as creation date, author, and tool version.
2. Profile-specific metadata
   • Defines metadata fields specific to each profile (Software, Security, License, etc.).

Extensibility Mechanisms

1. Custom attributes
   • Can include additional user-defined attributes beyond the standard fields.
2. External references
   • Provides links to external systems or documents.

Data Types

SPDX 3.0 supports various data types:

• Strings, integers, booleans, date/time
• Enumerations (e.g., license type, relationship type)
• Composite types (e.g., version range, checksum)

Serialization Formats

The SPDX 3.0 data model can be serialized into various formats:

• JSON-LD
• YAML
• RDF
• XML

This support for multiple formats facilitates integration with other systems.

Profile Support

The data model is designed to support various profiles:

• Core Profile: Basic elements common to every SPDX document
• Software Profile: Information related to software packages
• Security Profile: Vulnerability and security-related data
• License Profile: Detailed license information
• AI/ML Profile: Metadata related to AI models
• Dataset Profile: Information related to datasets

Each profile defines the additional fields and relationships required for a specific use case. The data model of SPDX 3.0 can comprehensively express the complexity of the software supply chain while providing the flexibility to meet the requirements of specific domains. This enables organizations to manage and share more accurate and detailed information about their software components.

5. SPDX 3.0 Implementation Guide

This section provides a detailed guide for effectively implementing SPDX 3.0.

Tools and Libraries

The main tools and libraries that support SPDX 3.0 are as follows:

1. SPDX Java Library
   • GitHub:https://github.com/spdx/tools-java
   • Features: Parsing, generating, converting, and validating SPDX documents
   • Usage: Add as a Maven dependency for use in Java projects
2. SPDX Python Library
   • GitHub:https://github.com/spdx/tools-python
   • Features: Parsing, generating, and validating SPDX documents
   • Characteristics: Provides experimental support for SPDX 3.0
3. SPDX Online Tools
   • Website:https://tools.spdx.org
   • Features: Web-based SPDX document generation and validation
4. FOSSology
   • GitHub:https://github.com/fossology/fossology
   • Features: An open source compliance tool that supports SPDX document generation
5. SPDX SBOM Generator
   • GitHub:https://github.com/opensbom-generator/spdx-sbom-generator
   • Features: Generates SPDX SBOMs for projects in various programming languages

These tools can be used to generate, parse, and validate SPDX 3.0 documents.

File Formats (JSON, YAML, RDF)

SPDX 3.0 supports various file formats:

1. JSON-LD

   • The most recommended format

   • Example:

     {"@context":"<https://spdx.org/spdx-3.0-context.jsonld>","@type":"SpdxDocument","name":"Example SPDX 3.0 Document","elements":[{"@type":"Package","name":"ExamplePackage","version":"1.0.0"}]}

2. YAML

   • A human-readable format

   • Example:

     ---$schema:<https://spdx.org/spdx-3.0-schema.json>spdxVersion:SPDX-3.0name:Example SPDX 3.0 Documentelements:-type:Packagename:ExamplePackageversion:1.0.0

3. RDF

   • Suitable for semantic web applications

   • Example:

     <rdf:RDFxmlns:rdf="<http://www.w3.org/1999/02/22-rdf-syntax-ns#>"xmlns:spdx="<http://spdx.org/rdf/terms#>"><spdx:SpdxDocument><spdx:name>Example SPDX 3.0 Document</spdx:name><spdx:element><spdx:Package><spdx:name>ExamplePackage</spdx:name><spdx:versionInfo>1.0.0</spdx:versionInfo></spdx:Package></spdx:element></spdx:SpdxDocument></rdf:RDF>

Each format is suited to specific use cases, and developers can choose the appropriate format based on their project requirements.

Migrating from Existing SPDX 2.x

The process of migrating from SPDX 2.x to 3.0 is as follows:

1. Understand the structural changes
   • Familiarize yourself with the modular structure and profile concept of SPDX 3.0
   • Identify new fields and relationship types
2. Update tools
   • Upgrade to the latest versions of tools and libraries that support SPDX 3.0
3. Convert documents
   • Use thespdx_tools.spdx3.bump_from_spdx2.spdx_document module of the SPDX Python Library
   • Convert SPDX 2.x documents to 3.0 using thebump_spdx_document() function
4. Add new fields
   • Add fields newly introduced in SPDX 3.0 (e.g., AI/ML-related information)
5. Redefine relationships
   • Redefine existing relationships using the new relationship types in SPDX 3.0
6. Apply profiles
   • Select and apply the appropriate SPDX 3.0 profiles
7. Validate
   • Use SPDX 3.0 validation tools to verify the validity of the converted document
8. Test and integrate
   • Integrate and test the converted SPDX 3.0 document within the existing workflow

During the migration process, it is advisable to actively make use of SPDX community resources and documentation, and to seek expert help if needed.

By following this implementation guide, organizations can effectively adopt and utilize SPDX 3.0.

Citations:
[1]https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[2]https://www.youtube.com/watch?v=iqVk-Sek8Pc
[3]https://github.com/spdx/Spdx-Java-Library
[4]https://spdx.github.io/spdx-spec/v3.0/annexes/diffs-from-previous-editions/
[5]https://github.com/spdx/spdx-3-model/releases
[6]https://spdx.dev/use/spdx-tools/
[7]https://github.com/spdx/tools-python/blob/main/README.md
[8]https://fossa.com/learn/spdx

6. SBOM and SPDX 3.0

The Software Bill of Materials (SBOM) has become a core element of software supply chain security. SPDX 3.0 provides a powerful framework for generating and managing SBOMs, enabling organizations to track and manage software components more effectively.

SBOM Generation and Management

1. Automated SBOM generation
   • SPDX 3.0 can be integrated into CI/CD pipelines to automatically generate SBOMs[6].
   • This enables “machine-speed” SBOM generation, allowing SBOMs to be updated instantly in step with the software release cycle.
2. Use of a consistent format
   • SPDX 3.0 provides a standardized SBOM format to ensure consistency[6].
   • This facilitates SBOM data exchange between organizations and enables automated analysis.
3. Regular updates
   • The SBOM must be updated with every software release[6].
   • Leveraging the automation features of SPDX 3.0 makes it possible to manage this process efficiently.
4. Inclusion of metadata
   • SPDX 3.0 allows rich metadata, such as license information and patch status, to be included in the SBOM[6].
   • This greatly improves security and compliance management.

Improving SBOMs with SPDX 3.0

1. Modular structure
   • The profile-based structure of SPDX 3.0 can be used to generate SBOMs tailored to various use cases[1].
   • Information specific to each profile, such as Software, Security, and License, can be included in the SBOM.
2. Integration of security vulnerability information
   • The Security Profile of SPDX 3.0 can be used to include vulnerability information directly in the SBOM[1].
   • This allows security teams to identify and respond to vulnerabilities more quickly and effectively.
3. Strengthened license compliance
   • The License Profile of SPDX 3.0 can be used to include detailed license information in the SBOM[2].
   • This makes it easier for legal and compliance teams to identify and manage license obligations.
4. Inclusion of AI/ML model information
   • The AI/ML Profile of SPDX 3.0 can be used to include AI model and dataset information in the SBOM[2].
   • This contributes to increasing the transparency and accountability of AI systems.

Meeting NTIA Minimum Requirements

SPDX 3.0 meets the SBOM minimum requirements defined by the National Telecommunications and Information Administration (NTIA)[4][5].

1. Basic data fields
   • SPDX 3.0 includes all seven basic data fields required by the NTIA:
     • Supplier Name
     • Component Name
     • Component Version
     • Other Unique Identifiers
     • Dependency Relationship
     • SBOM Author
     • Timestamp
2. Automation and interoperability
   • SPDX 3.0 supports machine-readable formats (JSON-LD, YAML, RDF), meeting the NTIA’s automation requirements[5].
3. Practicability
   • SPDX 3.0 ensures practicability by supporting SBOM generation and management through a variety of tools and libraries.
4. Extensibility
   • The modular structure of SPDX 3.0 provides the extensibility to accommodate future requirements.

SBOM management using SPDX 3.0 goes beyond simply meeting regulatory requirements — it significantly strengthens an organization’s software supply chain security and contributes to greater transparency. This ultimately leads to the construction of a safer and more trustworthy software ecosystem.

Citations:
[1]https://spdx.dev/capturing-software-vulnerability-data-in-spdx-3-0/
[2]https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[3]https://www.legitsecurity.com/blog/best-practices-for-managing-maintaining-sboms
[4]https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
[5]https://cybellum.com/blog/ntia-minimum-elements-for-a-software-bill-of-materials-sbom-a-guide/
[6]https://jfrog.com/devops-tools/article/best-practices-for-software-bill-of-materials-management/
[7]https://about.gitlab.com/blog/2022/10/25/the-ultimate-guide-to-sboms/
[8]https://scribesecurity.com/sbom/how-to-generate-an-sbom/

7. Security and Vulnerability Management

SPDX 3.0 provides powerful features for software security and vulnerability management. This enables organizations to manage the security of their software supply chain more effectively.

CVE Information Integration

Integrating Common Vulnerabilities and Exposures (CVE) information into SPDX 3.0 documents is a core element of security management.

1. How to reference CVEs

   • SPDX 3.0 uses theExternalReference class to reference CVE information.

   • Example:

     {"@type":"ExternalReference","referenceType":"SecurityAdvisory","referenceLocator":"CVE-2021-44228","referenceCategory":"CVE"}

2. Inclusion of detailed CVE information

   • Common Vulnerability Scoring System (CVSS) score
   • Affected version range
   • Patch availability and patch information

3. Automatic CVE updates

   • SPDX 3.0 tools can automatically pull CVE information from external sources such as the National Vulnerability Database (NVD) to update SPDX documents.

4. Linking CVE information to components

   • SPDX 3.0 can clearly link specific software components with related CVE information.
   • This makes it easy to identify and track vulnerable components.

Vulnerability Tracking and Reporting

SPDX 3.0 provides features for effectively tracking and reporting vulnerabilities.

1. Vulnerability lifecycle management

   • The entire lifecycle of a vulnerability, including discovery date, report date, and patch date, can be tracked.

   • Example:

     {"@type":"Vulnerability","name":"CVE-2021-44228","description":"Log4j RCE vulnerability","discoveredDate":"2021-12-09","publishedDate":"2021-12-10","patchedDate":"2021-12-14"}

2. Vulnerability severity assessment

   • The severity of a vulnerability can be assessed and recorded using the CVSS score.

   • Example:

     {"@type":"VulnerabilityAssessment","vulnerability":"CVE-2021-44228","cvssV3":{"baseScore":10.0,"vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"}}

3. Vulnerability report generation

   • Automated vulnerability reports can be generated based on SPDX 3.0 data.
   • The report includes the affected components, severity, patch status, and more.

4. Vulnerability trend analysis

   • Patterns in vulnerability occurrence over time can be analyzed.
   • This allows security teams to establish long-term security strategies.

Utilizing the Security Profile

The Security Profile of SPDX 3.0 enables systematic management of security-related information.

1. Security Profile structure

   • Vulnerability: A class representing vulnerability information
   • VulnerabilityAssessment: A class representing vulnerability assessment information
   • SecurityAdvisory: A class representing security advisories

2. Example use of the Security Profile

   {"@type":"SecurityProfile","vulnerabilities":[{"@type":"Vulnerability","name":"CVE-2021-44228","description":"Log4j RCE vulnerability"}],"assessments":[{"@type":"VulnerabilityAssessment","vulnerability":"CVE-2021-44228","cvssV3":{"baseScore":10.0,"vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"}}],"advisories":[{"@type":"SecurityAdvisory","title":"Update Log4j to version 2.15.0 or later","description":"Upgrade Log4j to mitigate CVE-2021-44228"}]}

3. Ways to utilize the Security Profile

   • Automatically update the Security Profile by integrating with vulnerability scanning tools
   • Use as a data source for building security dashboards
   • Use as evidence of security posture during compliance audits

4. Security metric tracking

   • Security metrics such as the number of open vulnerabilities, average patch time, and the ratio of high-risk vulnerabilities can be tracked based on SPDX 3.0 data.

By leveraging the security and vulnerability management features of SPDX 3.0, organizations can greatly strengthen the security of their software supply chain. Integrating CVE information, systematically tracking and reporting vulnerabilities, and utilizing the Security Profile help security teams respond to threats more effectively and improve the organization’s overall security posture.

8. License Compliance

SPDX 3.0 provides powerful features for effectively managing software license compliance. This allows organizations to more easily identify and comply with the license obligations of open source and commercial software.

License Information Management

1. License identifiers

   • SPDX 3.0 uses standardized license identifiers.
   • Example: “MIT”, “Apache-2.0”, “GPL-3.0-only”
   • This ensures the consistency and accuracy of license information.

2. Inclusion of license text

   • The full license text can be included in the SPDX document.

   • Example:

     {"@type":"License","licenseId":"MIT","name":"MIT License","text":"MIT License\\n\\nCopyright (c) [year] [fullname]\\n\\nPermission is hereby granted, ..."}

3. Custom licenses

   • For licenses not on the standard SPDX license list, a custom license can be defined.
   • In this case, the “LicenseRef-” prefix is used.
   • Example: “LicenseRef-CompanyA-Proprietary”

4. License expressions

   • Complex license combinations can be expressed.
   • Example: “(MIT OR Apache-2.0) AND CC-BY-4.0”

5. File- and package-level licenses

   • License information can be specified at the level of individual files, snippets, or packages.
   • This allows for fine-grained license management.

License Compatibility Checking

SPDX 3.0 data can be used to automatically check license compatibility.

1. License graph generation
   • A license graph is generated based on the dependencies between software components and the license information of each component.
2. Compatibility rule definition
   • Compatibility rules between licenses are defined.
   • Example: GPL-3.0 is compatible with Apache-2.0, but GPL-2.0 is not compatible with Apache-2.0.
3. Automatic compatibility checking
   • The license graph is analyzed based on the defined rules to automatically identify compatibility issues.
4. Conflict resolution suggestions
   • When a license conflict is found, possible resolutions are suggested.
   • Example: Using an alternative version of a specific component, requesting a license exception, etc.
5. Dynamic analysis
   • License compatibility can be checked in real time during the software build process.
   • This allows license issues to be identified and resolved early in development.

Compliance Report Generation

Detailed license compliance reports can be generated based on SPDX 3.0 data.

1. Report components
   • A list of all software components used
   • License information for each component
   • A summary of license obligations
   • Potential license conflicts and resolutions
   • Copyright notice text
2. Obligation tracking
   • Tracks the key obligations of each license and reports on compliance status.
   • Example: the obligation to disclose source code, the obligation to provide copyright notice, the obligation to include license text, etc.
3. Risk assessment
   • Assesses and reports the legal risk of each license and license combination.
   • Provides warnings about the use of high-risk licenses.
4. Compliance workflow integration
   • Report generation can be automated and integrated into regular compliance review processes.
   • It can be integrated into a CI/CD pipeline to generate a compliance report with every build or release.
5. Customized reports
   • Customized reports can be generated to meet the needs of various stakeholders (legal team, development team, management, etc.).
   • Example: detailed reports for the legal team, summary reports for management, etc.
6. History management
   • Changes in compliance status over time can be tracked.
   • This makes it possible to measure the effectiveness of license compliance improvement efforts.

By leveraging the license compliance features of SPDX 3.0, organizations can effectively manage and comply with license obligations within a complex software ecosystem. This helps reduce legal risk, improve relationships with the open source community, and increase the transparency and reliability of the overall software development process.

9. SPDX 3.0 Use Cases

SPDX 3.0 can be used to improve software management and security across a variety of industries. The main use cases are as follows:

Software Supply Chain Security

1. Vulnerability identification and management
   • The Security Profile of SPDX 3.0 is used to systematically track vulnerabilities in software components.
   • CVE information can be integrated into the SPDX document to assess security risk in real time.
2. Ensuring supply chain transparency
   • SPDX 3.0 makes it possible to clearly document all components of software and their provenance.
   • This helps reduce the risk of malicious code injection or supply chain attacks.
3. Build process security
   • The Build Profile of SPDX 3.0 can be used to ensure the integrity of the software build process.
   • Documenting information such as build tools, environment, and scripts supports reproducible builds.
4. Rapid application of security patches
   • SPDX 3.0 documents make it possible to quickly identify and patch vulnerable components.
   • The security update process can be optimized by integrating with automated tools.

Open Source Management

1. License compliance
   • The License Profile of SPDX 3.0 is used to systematically manage open source license obligations.
   • Complex license combinations can be accurately expressed and analyzed.
2. Open source contribution tracking
   • SPDX 3.0 makes it possible to clearly record the provenance and contributor information of open source components within a project.
   • This helps strengthen collaboration with the open source community and recognize contributions.
3. Open source policy enforcement
   • SPDX 3.0 documents can be linked to an organization’s open source policy to ensure that only approved licenses and components are used.
4. Streamlining open source audits
   • The standardized format of SPDX 3.0 makes it possible to automate and streamline the open source audit process.

Regulatory Compliance

1. Meeting SBOM requirements
   • SPDX 3.0 meets the SBOM generation requirements set out in US government Executive Order 14028 and the EU Cyber Resilience Act, among others.
2. Responding to industry-specific regulations
   • SPDX 3.0 makes it possible to effectively respond to software-related regulatory requirements across various industries, including medical devices, automotive, and aerospace.
3. Data privacy regulatory compliance
   • The Dataset Profile of SPDX 3.0 can be used to support compliance with data privacy regulations such as GDPR and CCPA.
4. Support for audits and reporting
   • SPDX 3.0 documents make it easy to provide regulators or auditors with the necessary software composition and security information.
5. Responding to AI regulation
   • By using the AI/ML Profile of SPDX 3.0 to document an AI model’s training data, algorithms, and performance metrics, organizations can proactively prepare for future AI regulation.

These use cases of SPDX 3.0 enable organizations to improve software management, security, and compliance in an integrated way. Its standardized approach promotes collaboration between organizations and contributes to increasing transparency and reliability across the software ecosystem.

Citations:
[1]https://linuxsecurity.com/news/organizations-events/spdx-3-0
[2]https://spdx.dev/spdx-announces-3-0-release-candidate-with-new-use-cases/
[3]https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[4]https://www.prnewswire.com/news-releases/spdx-3-0-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases-302118321.html
[5]https://spdx.dev/leveraging-profiles-for-license-compliance-insights-from-spdx-mini-summit/
[6]https://www.synopsys.com/blogs/software-security/sboms-and-spdx.html
[7]https://spdx.dev/understanding-spdx-profiles/

10. SPDX 3.0 Adoption Strategy

A systematic approach is needed to successfully adopt SPDX 3.0 within an organization. The following is a detailed strategy for adopting SPDX 3.0.

Phased Implementation Plan

1. Current state analysis
   • Assess the current SBOM generation and management process
   • Analyze existing tools and workflows
   • Identify the benefits that adopting SPDX 3.0 can bring
2. Pilot project selection
   • Select a small, low-criticality project
   • Select and apply a specific SPDX 3.0 profile (e.g., Security or License)
3. Tool selection and configuration
   • Evaluate tools that support SPDX 3.0 (e.g., SPDX tools, FOSSology)
   • Integrate the selected tools into the existing CI/CD pipeline
4. Process definition
   • Design workflows for generating, validating, and managing SPDX 3.0 documents
   • Define owners and roles
5. Expansion plan
   • Identify improvements based on the pilot project’s results
   • Gradually expand adoption to other projects and departments
6. Monitoring and optimization
   • Set KPIs to measure the impact of SPDX 3.0 adoption
   • Conduct regular reviews and process improvements

Training and Awareness Within the Organization

1. Securing executive support
   • Present the business value of adopting SPDX 3.0
   • Emphasize regulatory compliance and risk management aspects
2. Department-specific training
   • Development team: How to generate and manage SPDX 3.0 documents
   • Legal team: Ways to improve license compliance
   • Security team: Vulnerability management and how to use the Security Profile
3. Workshops and hands-on sessions
   • Hands-on practice using SPDX 3.0 tools
   • Practice applying SPDX 3.0 to real projects
4. Internal communication
   • Publish newsletters related to SPDX 3.0
   • Build an SPDX 3.0 resource center on the intranet
5. Sharing success stories
   • Share the outcomes and lessons learned from the pilot project
   • Highlight the improvements achieved through SPDX 3.0 adoption

Tips for Successful Adoption

1. Gradual approach
   • Do not try to change everything at once; adopt it in stages
   • Collect feedback and identify improvements at each stage
2. Forming a cross-functional team
   • Form a team of experts from various departments, including development, legal, security, and operations
   • Discuss progress and issues through regular meetings
3. Emphasizing automation
   • Automate the process of generating and managing SPDX 3.0 documents
   • Integrate SPDX 3.0-related steps into the CI/CD pipeline
4. Leveraging external experts
   • Seek help from the SPDX community or consulting firms as needed
   • Benchmark the success stories of other organizations
5. Maintaining flexibility
   • Do not try to adopt all features of SPDX 3.0 at once
   • Start with the profiles and features that fit the organization’s needs
6. Emphasizing continuous learning
   • Encourage participation in SPDX community activities
   • Support attendance at related conferences and webinars
7. Measuring and reporting outcomes
   • Compare metrics before and after SPDX 3.0 adoption (e.g., vulnerability response time, improvement in license compliance)
   • Regularly report progress and ROI to management
8. Managing cultural change
   • Encourage the organization to see SPDX 3.0 not merely as a tool but as a new way of working
   • Develop strategies to overcome resistance to change

Successful adoption of SPDX 3.0 involves not only technical implementation but also changes in organizational culture and processes. Through systematic planning, continuous education, and a flexible approach, organizations can make the most of the benefits of SPDX 3.0[1][2].

Citations:
[1]https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[2]https://spdx.dev/unpacking-the-spdx-3-0-tooling-mini-summit-a-new-era-of-compliance-and-security/
[3]https://spdx.dev/spdx-announces-3-0-release-candidate-with-new-use-cases/
[4]https://openchainproject.org/news/2023/03/31/webinar-50
[5]https://nand-research.com/quick-take-spdx-3-0-release/
[6]https://linuxsecurity.com/news/organizations-events/spdx-3-0
[7]https://spdx.dev/leveraging-profiles-for-license-compliance-insights-from-spdx-mini-summit/

11. Future Outlook and Direction

The release of SPDX 3.0 has opened a new chapter in software supply chain management. This section takes a closer look at the future and direction of SPDX.

SPDX Community Participation

1. Open participation model
   • SPDX has adopted an open community model, so anyone can participate[1].
   • A variety of stakeholders — individuals, companies, and organizations — can contribute to the development of SPDX.
2. How to participate
   • Subscribe to the mailing list: You can join the general SPDX mailing list to receive the latest news[1].
   • Attend regular meetings: You can join the monthly general meeting to follow project progress and share your input[1].
   • Work group activities: You can participate in various working groups such as technical, legal, and outreach.
3. Participation in tool development
   • You can participate directly in SPDX tool development. For example, students can contribute to SPDX-related projects through the Google Summer of Code program[7].

Future Updates and Improvements

1. Enhancement of AI/ML-related features
   • Profiles covering AI model training and characterization, dataset provenance, and similar topics are expected to be further developed[4].
   • Adding metadata related to AI ethics and accountability may be considered.
2. Expansion of security features
   • The linkage between vulnerability information and SBOMs is expected to be further strengthened.
   • Integration with real-time threat intelligence is a possibility.
3. Improved automation and integration
   • Deeper integration with CI/CD pipelines is expected.
   • Automated SBOM generation and update features will become more sophisticated.
4. Improved user experience
   • More intuitive user interfaces and visualization tools may be developed.
   • Simplified versions of SPDX tools for non-technical users may emerge.

Global Standardization Trends

1. Strengthening its position as an ISO standard
   • SPDX has already been adopted as the ISO/IEC 5962:2021 standard, and version 3.0 is also planned to be submitted to ISO[5].
   • This is expected to further accelerate the global adoption of SPDX.
2. Responding to international regulations
   • It is expected to become a core tool for addressing international software supply chain security regulations, such as US Executive Order 14028 and the EU Cyber Resilience Act[6].
3. Industry-specific standardization
   • Industry-specific standards based on SPDX may be developed across various sectors, including automotive, medical devices, and aerospace.
4. Strengthening international cooperation
   • The SPDX community is expected to strengthen cooperation with other international standards bodies and open source foundations.
   • This could lead to a more unified global approach to software supply chain security.

SPDX 3.0 is an important milestone shaping the future of software management. Through continued community participation, technological advancement, and international standardization efforts, SPDX is expected to continue making a significant contribution to improving software supply chain security and transparency.

Citations: [1]https://spdx.dev/engage/participate/
[2]https://www.linuxinsider.com/story/spdx-becomes-new-standard-for-open-source-software-security-87265.html
[3]https://spdx.dev/engage/join/
[4]https://sbomify.com/2024/04/28/exploring-the-new-spdx-3-0-a-game-changer-for-sboms/
[5]https://www.prnewswire.com/news-releases/spdx-3-0-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases-302118321.html
[6]https://spdx.dev/spdx-announces-3-0-release-candidate-with-new-use-cases/
[7]https://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeas
[8]https://linuxsecurity.com/news/organizations-events/spdx-3-0

12. Conclusion: SPDX 3.0 Utilization Strategy for Enterprise Open Source Managers

SPDX 3.0 provides enterprise open source managers with a powerful and flexible tool. The following are strategic approaches for making effective use of SPDX 3.0:

1. Strategic adoption
   • Recognize SPDX 3.0 not merely as a tool but as a strategic asset.
   • Link SPDX 3.0 with the organization’s open source policy to build a consistent management system.
2. Automation first
   • Automate the process of generating and managing SPDX 3.0 documents as much as possible.
   • Integrate SPDX 3.0-related steps into the CI/CD pipeline to achieve continuous monitoring.
3. Strengthened risk management
   • Use the Security and License profiles of SPDX 3.0 to systematically manage the risks of using open source.
   • Conduct regular open source audits based on SPDX 3.0 to ensure compliance.
4. Decision support
   • Use SPDX 3.0 data to support informed decision-making about the adoption and use of open source.
   • Use it to develop a data-driven open source strategy.
5. Promoting collaboration
   • Use SPDX 3.0 to strengthen collaboration between the development, legal, and security teams.
   • Use its standardized format to facilitate information exchange with external partners.
6. Education and capability building
   • Open source managers should lead internal training based on a deep understanding of SPDX 3.0.
   • Actively participate in SPDX community activities to keep up with the latest trends and learn best practices.
7. Preparing for regulatory response
   • Use SPDX 3.0 to proactively address SBOM-related regulatory requirements.
   • Build a system that can flexibly respond to future regulatory changes.
8. Value creation
   • Use SPDX 3.0 to increase the efficiency of open source management and translate this into strengthened organizational competitiveness.
   • Document open source contribution activities with SPDX 3.0 to enhance the company’s technical capability and reputation.
9. Continuous improvement
   • Regularly evaluate the current state of SPDX 3.0 utilization and identify areas for improvement.
   • Quickly incorporate new profiles or features into the organization’s processes as they are added.
10. Leading innovation
    • Develop an organization-specific open source management model based on SPDX 3.0.
    • This helps secure a leading position in open source management within the industry.

In conclusion, SPDX 3.0 provides enterprise open source managers with a powerful tool for effectively managing and leveraging the open source ecosystem. By taking a strategic and systematic approach to using SPDX 3.0, organizations can maximize the benefits of open source while minimizing the associated risks. Through this tool, open source managers can play a central role in driving their organization’s digital transformation and strengthening its competitiveness.

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

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)