Research

• 1: CISA 2026 SBOM Minimum Elements: What to Prepare and Which Tools Fill the Gaps
• 2: Enterprise AI BOM Field Requirements Matrix — Required and Optional Fields Defined by Standards and Regulatory Grounds
• 2.1: Supplier AI BOM Submission Requirements
• 2.2: AI BOM Authoring Guidelines for In-House Development Teams
• 2.3: Ingestion Vetting Checklist for External Models and Datasets
• 2.4: AI BOM Toolset Design Strategy
• 3: A Look at the 2026 Software Supply Chain Security Roadmap
• 4: G7 "Software Bill of Materials for AI — Minimum Elements": AI Supply Chain Transparency Guidance by Cluster and Element
• 5: OpenChain AI SBOM Compliance Management Guide: Minimum Requirements for an AI Supply Chain Compliance Program
• 6: What the US AI Executive Order (2026-06-02) Means for Corporate Open Source Managers
• 7: EU Open Source Strategy: Institutionalizing Open Source for Technological Sovereignty
• 8: EU Cyber Resilience Act (CRA) Vulnerability Reporting Obligations — A Research Report on Preparing for the September 11, 2026 Effective Date

1 - CISA 2026 SBOM Minimum Elements: What to Prepare and Which Tools Fill the Gaps

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 the public 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 standard NOASSERTION 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 as pre-build and container and binary scans as post-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 write unknown; 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 writing unknown 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 the public 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 the G7 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.

2 - Enterprise AI BOM Field Requirements Matrix — Required and Optional Fields Defined by Standards and Regulatory Grounds

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’s AIPackage, the Dataset Profile’s DatasetPackage, and the common classes in Core.
• CycloneDX 1.6: required fields are defined by the required 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’s AIPackage/DatasetPackage), document-root requirements (CycloneDX’s bomFormat/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 use Required (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’s Required (P) denotes process enforcement rather than a data field. The role columns use Required, 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 use Required, 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

2.1 - Supplier AI BOM Submission Requirements

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 the AI 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 the Ingestion Vetting Checklist.

2.2 - AI BOM Authoring Guidelines for In-House Development Teams

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 the AI 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?

2.3 - Ingestion Vetting Checklist for External Models and Datasets

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 the AI 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.

2.4 - AI BOM Toolset Design Strategy

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. The aibom 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 cdxgen aibom, 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 CycloneDX properties 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. The AI 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 paths
model_license:
  g7: Model license
  cyclonedx: "components[?type=='machine-learning-model'].licenses"
  spdx: "Relationship(hasDeclaredLicense) from AIPackage"
dataset_provenance:
  g7: Dataset provenance
  cyclonedx: "components[?type=='data'].data[].governance"
  spdx: "DatasetPackage.originatedBy / dataCollectionProcess"
vulnerability_referencing:
  g7: Vulnerability referencing
  cyclonedx: "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_referencing
recommended:
  - 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 checking
package aibom

deny[msg] {
    role := input.metadata.properties[_].value  # e.g. "supplier"
    req := data.policy[role].required[_]
    not field_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 CycloneDX properties 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 (preserving properties) 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 the aibom CLI, --spec-version. https://github.com/CycloneDX/cdxgen (accessed 2026-06). — Used for: basis that cdxgen’s aibom 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 defines machine-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.

3 - A Look at the 2026 Software Supply Chain Security Roadmap

Citation and Commentary Notice. This article cites and comments on the Software Supply Chain Security Roadmap for the Age of Everyday AI (2026-06-24), publicly published by the Ministry of Science and ICT, the National Intelligence Service, and the Korea Internet & Security Agency, with attribution under Article 28 of the Copyright Act. The tables and diagrams in the original are not reproduced; the narrative and diagrams here are original work based on external primary sources. Attribution: Ministry of Science and ICT, National Intelligence Service, Korea Internet & Security Agency, Software Supply Chain Security Roadmap for the Age of Everyday AI, 2026-06-24.

Summary On June 24, 2026, the government released a roadmap outlining software supply chain security policy for the next three years. At its core are a transparency management model centered on the Software Bill of Materials (SBOM), a testbed and consulting program to help companies check their security, pilot certification to identify high-performing companies, and a rapid detection-and-response system. Notably, the roadmap places burden reduction for small and medium-sized enterprises throughout, reflecting an industry structure in which 81% of all software companies have fewer than 10 employees. Because the U.S. Food and Drug Administration (FDA)’s medical device approval process and the EU Cyber Resilience Act (CRA) have already made SBOMs a condition of market entry, this roadmap bears directly on the practical work of exporting companies, public-sector software vendors, and small and medium-sized software companies.

1. Nature of the Roadmap and Background to the Announcement

On June 24, 2026, the government released the Software Supply Chain Security Roadmap for the Age of Everyday AI at the Supply Chain Security Workshop held at the aT Center in Yangjae, SeoulA1·B-news-zdnet. The Ministry of Science and ICT, the National Intelligence Service, and the Korea Internet & Security Agency (KISA) prepared it jointly with related ministries, and KISA is the publisherA1. Rather than a law or notice, it is an administrative planning document setting out policy direction for the next three years; many of its individual tasks will gain normative force only after legal and institutional reform, guideline publication, and certification-system reorganizationA1.

The announcement followed an already-signaled path. When the government released the SW Supply Chain Security Guideline 1.0 in 2024, it stated that it would form a joint industry-academia-research task force in the second half of the year to discuss the direction of institutionalization and then prepare a roadmapD6; after the Ministry of Science and ICT and the National Intelligence Service agreed on December 24, 2025 to build a government-wide cooperation frameworkB-news-etnews, that process led to this announcement. The government has consistently described 2027 as its target for institutionalizationB-news-zdnet.

The roadmap declares its vision as “securing cyber resilience through a transition to a safe and responsible supply chain security system,” converging this into three pillars: prevention, recovery, and foundationA1. Beneath these sit three implementation strategies and nine detailed tasks.

Figure 1. The vision, the three strategies, and each strategy’s core tasks (compiled for this report; see §5 for external sources).

2. Prevention — Building In Security and SBOM Transparency

The prevention strategy starts from establishing standards and guidance that build security into the software lifecycle as a whole. The roadmap presents a “secure SW development methodology” that draws on the National Institute of Standards and Technology (NIST)’s Secure Software Development Framework (SSDF, SP 800-218), and states that it will place activities such as defining security requirements, secure coding, vulnerability re-verification, and code signing at each stage — planning and design, development, testing, and deploymentA1·B5. Its predecessor, the SW Supply Chain Security Guideline 1.0, will be upgraded to a practically usable 2.0. The direction is to broaden open source management, which had centered on licensing, to cover security as well; to extend development security, which had focused on self-developed code, across the full supply chain; and to newly add the use of automated security compliance toolsA1·A2.

SBOM is the core instrument of the transparency task. An SBOM is a specification that describes information about a software’s components; domestically it is also called a “software component specification,” among other names. The roadmap identifies exporting companies and high-impact sectors as the priority targets for applying the SBOM management modelA1. For exporting companies, the direct drivers are the U.S. FDA’s medical device approval process, the U.S. Department of Commerce’s SBOM management obligation for connected vehicles, and the EU CRA’s SBOM obligation for products with digital elementsA1·B7·B1; high-impact sectors include security software, socially foundational software such as finance and transportation, and software handling sensitive information such as health and medical dataA1.

The data format is effectively already settled. The International Organization for Standardization (ISO) standardized the Linux Foundation’s SPDX as ISO/IEC 5962:2021C4, and OWASP’s CycloneDX was standardized as ECMA-424, published in December 2025C5. The roadmap’s statement that it will “derive the minimum SBOM items so they do not function as dual regulation,” made with an eye to the National Telecommunications and Information Administration (NTIA)’s The Minimum Elements For a Software Bill of Materials (2021) and the CRA’s requirements, is a design aimed at aligning with this international formatA1·C1. Format compatibility is only the starting point; the roadmap itself names verifying SBOM trustworthiness and safely distributing the vulnerability information it contains as remaining tasksA1. An SBOM raises transparency but can also reveal to attackers which components carry which vulnerabilities, so designing the right balance between generation and sharing is the key question for the follow-on guidelinesA1.

3. Recovery — Rapid Detection, Risk Management, and Reducing the Burden on Companies

The detection-and-response strategy centers on expanding the scope of KISA’s security vulnerability reward program (bug bounty), which it has run since October 2012D2, and on progressively expanding Coordinated Vulnerability Disclosure (CVD) and a Vulnerability Disclosure Policy (VDP)A1. To introduce security condition inspections for Internet of Things (IoT) appliances such as robot vacuums and IP cameras and for network-connected devices such as solar inverters, the government is pursuing an amendment to the Act on Promotion of Information and Communications Network Utilization and Information Protection, etc. (Network Act)A1.

The risk management system is split into public and private sectors. In the public sector, the government will develop an SBOM management framework that includes Vulnerability Exploitability eXchange (VEX) information at the reliability-assurance stage, and will build an integrated public-sector SBOM management system and a vulnerability information database in stagesA1. In the private sector, it will establish a standing management framework for high-risk vulnerabilities, and set a goal of shortening the response period “from an average of more than four months to within three days” through a cleaning service (C-Clean) that, once a vulnerability is found, requests a patch from the manufacturer and performs a mass removal via antivirus softwareA1.

The support companies actually feel is concentrated in inspection and diagnosis and in the distribution of tools and personnel. The roadmap states that it will expand testbeds where companies can use SBOM generation and vulnerability inspection tools, drawing on existing facilities such as the Development Security Hub and the National Cyber Security Center (NCSC) in Pangyo, and will add checks against global regulations such as medical device approval and the EU CRA to the menuA1. For small and medium-sized software development companies, it has placed consulting to analyze and diagnose development infrastructure and management systems starting in 2026, and the distribution of cloud-based development environments and security solutions starting in 2027A1. A defining feature of the roadmap overall is that it explicitly states the industry structure — 81% of all software companies have fewer than 10 employees (2023 Software Industry Survey, a total of 43,932 companies by employee-size bracket) — and designs its support accordinglyA1·D1.

4. Foundation — Policy Framework, Pilot Certification, and Global Cooperation

In the foundation-building strategy, the Ministry of Science and ICT and the National Intelligence Service will jointly chair a (tentatively named) government-wide SW Supply Chain Security Council, organized into five subcommittees: medical devices, automobiles, public information systems, finance, and securityA1. Pilot certification sits at the center of legal and institutional reform. The government states that it will verify software supply chain security management and issue certificates recognizing high-performing companies (tentatively named SSS Verified, Software Supply-Chain Security Verified), pursue Mutual Recognition Agreements (MRA) with countries that have institutionalized similar systems, and formally institutionalize the framework by incorporating supply chain security testing and evaluation elements into the Information Security Management System certification (ISMS), the Cloud Security Assurance Program (CSAP), and IoT security certificationA1. It is notable that the government chose to build on existing systems rather than create a separate new certification.

The changes on the public procurement side are also clear. SBOM submission and vulnerability response procedures, along with a supply chain cybersecurity risk management procedure document, have been added as tasks for informatization projects, and security conformity assessment will widen its scope in consideration of the National Network Security Framework (N2SF) while combining it with confirmation of SBOM submissionA1·D3. N2SF is a multi-tier security approach that applies differentiated security levels according to the importance of the work and data involved; its formal Security Guideline 1.0 was published on September 30, 2025, and reflected in the 2026 cybersecurity assessmentD3·D-news-boan.

The global cooperation task connects to two multilateral bodies. The Global Cybersecurity Labelling Initiative (GCLI), a coalition that discusses mutual recognition of IoT security certification labels and the establishment of a single standard, launched with 11 founding members at Singapore International Cyber Week on October 23, 2025, with Korea’s Ministry of Science and ICT and KISA participating as founding membersA10. Alongside this, the roadmap presents cooperation with the Global Government Expert Forum (GGEF), the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the European Commission’s Directorate-General for Communications Networks, Content and Technology (DG CONNECT), and the UK Department for Science, Innovation and Technology (DSIT) as channels for supporting global expansionA1.

Figure 2. The correspondence between the global regimes the roadmap references and its policy tasks (compiled for this report; see §5 for external sources).

The roadmap separates its response to emerging technologies into a distinct research task. It places research on a supply chain security model that responds to the everyday normalization of emerging technologies such as AI as a task for 2027 and beyondA1, and the data layer of an SBOM for AI (training data, model weights, and the like) falls outside the direct scope of this roadmap, which centers on the general software supply chain.

5. The Background Shaped by Global Regulation

Behind the roadmap’s choice of SBOM, pilot certification, and mutual recognition as its core instruments lies the overseas regulation exporting companies face. A company interview the roadmap quotes shows this plainly. A digital medical device manufacturer struggled to respond to SBOM requirements during the FDA approval process; a security company that had entered the U.S. market was notified, while supplying software to the federal government, that failing to meet SBOM management requirements would make it ineligible for next year’s contract; and an AI solution developer lost a contract during preparations to supply a global financial company because it failed to meet cybersecurity requirementsA1.

Figure 3. The overseas regulation behind the roadmap and the deadlines ahead (compiled for this report; see §7 for sources).

Most of these regulations were finalized between 2021 and 2024. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is a regulation that imposes horizontal cybersecurity requirements on products with digital elements, and it entered into force on December 10, 2024B1·B2. The Article 14 reporting obligation applies from September 11, 2026, and the essential obligations as a whole, including conformity assessment and CE marking, apply from December 11, 2027B2. Manufacturers bear the obligation to produce an SBOM for products with digital elements, to handle vulnerabilities across the full lifecycle, and to issue an early warning within 24 hours and notify within 72 hours of becoming aware of an actively exploited vulnerability or a severe incidentB1. Penalties for violation run up to €15 million or 2.5% of worldwide annual turnover, whichever is higherB1. The roadmap’s recurring “scheduled for ‘27.12 implementation” refers to this date of full applicationA1.

U.S. supply chain regulation began with Executive Order 14028 (Improving the Nation’s Cybersecurity), signed on May 12, 2021, which led to institutionalizing SBOM as a federal procurement requirement and directed NIST to draw up the SSDFB3·B5. CISA finalized the Secure Software Development Attestation Common Form on March 11, 2024B4. Medical device regulation began when Section 3305 of the 2022 Consolidated Appropriations Act added a new Section 524B to the Federal Food, Drug, and Cosmetic Act (FD&C Act); the amended provision took effect on March 29, 2023B7. Manufacturers filing a premarket submission must submit a postmarket vulnerability management plan, secure-by-design documentation, and an SBOM covering commercial, open source, and off-the-shelf componentsB7. In the consumer IoT space, the U.S. Federal Communications Commission (FCC) adopted a voluntary labeling program (the U.S. Cyber Trust Mark) on March 14, 2024B8, and the UK brought the Product Security and Telecommunications Infrastructure Act 2022 (PSTI) into force on April 29, 2024B9. These are the “U.S. Cyber Trust Mark” and “UK PSTI (effective ‘24.4)” the roadmap cites in its post-market management taskA1.

6. Implications and Considerations

6.1 Exporting Companies — SBOM Is Already a Market Entry Condition

With the FDA’s medical device approval process and the EU CRA having effectively made SBOM management a condition of market entry, the government’s inspection support and its push for mutual recognition offer direct value to exporting companiesA1·B1·B7. Because the EU CRA’s reporting obligation begins September 11, 2026, and full application begins December 11, 2027B2, exporting companies are safer preparing their SBOM generation and vulnerability reporting systems ahead of time on the CRA’s own schedule, rather than waiting for Korea’s MRA to be concluded. An MRA requires the counterpart country to recognize Korean certification as equivalent, and the roadmap itself only describes the MRA as being “pursued,” without offering a timeline for agreementA1.

6.2 Public-Sector Software Vendors — SBOM Submission Becomes a Standing Requirement

In the public sector, SBOM submission and vulnerability response procedures for informatization projects have been explicitly set as tasks, and confirmation of SBOM submission is combined with security conformity assessment and the transition to N2SFA1·D3. Companies supplying software to the public sector need to prepare by integrating SBOM generation into their build pipeline. Since the policy is to derive public-sector SBOM items at a minimum so they do not become dual regulationA1, it is practically useful to check the follow-on guidelines for how alignment with overseas requirements is actually designed.

6.3 Small and Medium-Sized Software Companies — Whether Support Is Sufficient Is the Question

In an industry structure where 81% of all software companies have fewer than 10 employeesA1·D1, it is difficult for these companies to bear on their own the tools and personnel needed for SBOM generation and vulnerability management. The roadmap places consulting and the distribution of cloud-based development environments and security solutions as its support measures, but no figures are given for whether the scale of distribution and the budget will actually cover the majority of the roughly 40,000 companies involvedA1. Whether the support is sufficient is an area that future budget allocation will decide.

6.4 Remaining Risks

There is a risk from dependence on external infrastructure. The contract between MITRE, which operates the U.S. Common Vulnerabilities and Exposures (CVE) program, and CISA came within a day of expiring on April 16, 2025, before an 11-month extension patched things over, and the CVE Board confirmed on January 21, 2026 that “there will be no March funding cliff”E6·F-news-cso. The immediate crisis was averted, but the structural instability of a global vulnerability identification system that depends on the U.S. government’s budget remains unchanged, which makes the roadmap’s inclusion of finding an alternative program as a task a reasonable precautionA1.

The readiness of the development field is another variable. According to Black Duck’s survey of the state of DevSecOps, conducted among 1,001 professionals worldwide in July and August 2025, 45.56% still handle putting new code through security testing manuallyH1. Speed has become the standard while security automation has not kept pace, and this gap overlaps with the problem the roadmap identifies in its plan to shift from human-centered manual response to an AI-centered autonomous systemA1. If SBOM generation and vulnerability inspection are not integrated into an automated pipeline, mandating them risks becoming, on the ground, an added burden of manual work.

As a side note, the estimate of global damage from supply chain attacks that the roadmap attributes to “Gartner (‘24.6)” — $46 billion in 2023, projected to reach $138 billion by 2031 — is actually a Cybersecurity Ventures estimateE4.

7. References

This section lists the items cited in the text as [A1] and similar. All URLs were accessed on 2026-06-24. Government and institutional sites sometimes return a bot block to automated crawling tools; these are not dead links, and such items were cross-checked using existing verification assets or WebSearch.

Subject of Analysis and Domestic Prior Documents

A1. Ministry of Science and ICT, National Intelligence Service, and Korea Internet & Security Agency, joint (2026). Software Supply Chain Security Roadmap for the Age of Everyday AI. Published by the Korea Internet & Security Agency (Naju), 1st edition, 1st printing, 2026-06-24. 30 pages, CC BY-NC-ND 2.0 KR. Released on the day of the announcement (2026-06-24, Supply Chain Security Workshop, aT Center, Yangjae); a fixed direct PDF link was not yet available, but it can be found via the Ministry of Science and ICT press release (https://www.msit.go.kr/bbs/list.do?sCode=user&mId=307&mPid=208) and the KISA resource library. — Use: the publicly released government roadmap that is the subject of this article’s citation and commentary. Cited with attribution; the original’s tables and diagrams are not reproduced. ↩

A2. Ministry of Science and ICT, National Intelligence Service, and Presidential Committee on Digital Platform Government (2024). SW Supply Chain Security Guideline 1.0 (summary, 2024-05-13). Published in the KISA resource library. https://www.kisa.or.kr/2060204/form?postSeq=15 (accessed 2026-06-24; publishing entity and SSDF, SBOM, and stage-by-stage inspection content cross-checked via WebSearch). — Use: the direct predecessor document the roadmap states it will upgrade to 2.0. ↩

A10. Cyber Security Agency of Singapore et al. (2025). Joint Statement on the Global Cybersecurity Labelling Initiative (GCLI). Launched 2025-10-23. https://www.csa.gov.sg/news-events/press-releases/joint-statement-on-the-global-cybersecurity-labelling-initiative/ (accessed 2026-06-24; launch date, 11 founding members, and Korea’s participation cross-checked via WebSearch). — Use: confirms the GCLI’s launch, composition, and Korea’s participation. ↩

Primary Texts of Global Laws and Regulations

B1. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal of the EU, OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed 2026-06-24; reconfirmed against the eu-cra-vulnerability-reporting workspace verification asset). — Use: primary basis for the CRA’s SBOM and vulnerability obligations, reporting deadlines (24h/72h), penalties, and effective dates. ↩

B2. European Commission, DG CNECT (2026). Cyber Resilience Act — Shaping Europe’s digital future. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (accessed 2026-06-24). — Use: primary confirmation of the implementation schedule (entry into force 2024-12-10, reporting obligation 2026-09-11, full application 2027-12-11). ↩

B3. The White House (2021). Executive Order 14028 — Improving the Nation’s Cybersecurity. Federal Register, 86 FR 26633, 2021-05-17. https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity (accessed 2026-06-24, 200 OK). — Use: primary basis for making SBOM a federal procurement requirement and directing NIST to draw up the SSDF. ↩

B4. CISA (2024). Secure Software Development Attestation Common Form (Final). Released 2024-03-11. https://www.cisa.gov/secure-software-attestation-form (accessed 2026-06-24; cisa.gov returned a bot block, release date cross-checked via WebSearch). — Use: the U.S. federal procurement SSDF self-attestation obligation. The roadmap’s “‘23.6~” notation refers to when the policy was discussed; the form itself was released in 2024-03. ↩

B5. NIST — Souppaya, M., Scarfone, K., Dodson, D. (2022). Secure Software Development Framework (SSDF) Version 1.1. NIST SP 800-218. DOI: 10.6028/NIST.SP.800-218. https://csrc.nist.gov/pubs/sp/800/218/final (accessed 2026-06-24). — Use: the framework the roadmap’s “secure SW development methodology” directly references. ↩

B7. U.S. Food and Drug Administration / Federal Register (2023). Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (FD&C Act §524B, added by §3305 of the 2022 Consolidated Appropriations Act, effective 2023-03-29). https://www.federalregister.gov/documents/2023/09/27/2023-20955/cybersecurity-in-medical-devices-quality-system-considerations-and-content-of-premarket-submissions (accessed 2026-06-24, 200 OK). — Use: primary basis for the FDA’s medical device SBOM requirement. ↩

B8. Federal Communications Commission (2024). Cybersecurity Labeling for Internet of Things — Report and Order (FCC 24-26) (U.S. Cyber Trust Mark). Adopted 2024-03-14. https://www.federalregister.gov/documents/2024/03/25/2024-06249/cybersecurity-labeling-for-internet-of-things (accessed 2026-06-24, 200 OK). Program hub: https://www.fcc.gov/CyberTrustMark. — Use: primary basis for the U.S. voluntary IoT labeling program. ↩

B9. UK Government / DSIT (2022/2024). Product Security and Telecommunications Infrastructure (PSTI) Act 2022, Part 1 (effective 2024-04-29). https://www.gov.uk/government/publications/the-uk-product-security-and-telecommunications-infrastructure-product-security-regime (accessed 2026-06-24; effective date and penalty cap cross-checked via WebSearch). — Use: primary basis for the UK’s mandatory PSTI regulation. ↩

Standards and Guidance

C1. U.S. Department of Commerce / NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM). 2021-07-12. https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf (accessed 2026-06-24; ntia.gov blocked the crawler, reconfirmed against the sbom-guide and g7-sbom-for-ai workspace verification assets). — Use: the baseline for the roadmap’s “deriving minimum SBOM items.” ↩

C4. The Linux Foundation / SPDX Project. SPDX Specifications (current version SPDX 3.0, standardized as ISO/IEC 5962:2021). https://spdx.dev/use/specifications/ (accessed 2026-06-24, 200 OK, verified against sbom-guide). — Use: an SBOM standard format. Basis for global compatibility. ↩

C5. OWASP Foundation / Ecma International (2025). CycloneDX Specification / ECMA-424 (published 2025-12-10). https://cyclonedx.org/specification/overview/ (accessed 2026-06-24, 200 OK, verified against sbom-guide). — Use: an SBOM standard format. ↩

Domestic Institutions and Statistics

D1. Ministry of Science and ICT and the Korea Association for ICT Promotion (KAIT) (2024). 2023 Software Industry Survey (a nationally approved statistic). Statistics portal SWSTAT: https://stat.spri.kr/ (accessed 2026-06-24; publishing body and the nature of the statistic confirmed via WebSearch). — Use: basis for the publishing framework behind the roadmap’s statistic that “81% of software companies have fewer than 10 employees (43,932 companies in total).” The 81% figure and the 43,932 count are attributed to the roadmap’s citation, as direct comparison against the survey’s original tables was not completed. ↩

D2. Korea Internet & Security Agency (KISA) / KrCERT (2012–). Security Vulnerability Reward Program (Bug Bounty). https://www.krcert.or.kr/kr/bbs/list.do?menuNo=205027 (accessed 2026-06-24; October 2012 program start and quarterly evaluation cross-checked via WebSearch). — Use: basis for the existing program the roadmap’s detection-and-response task expands. ↩

D3. National Intelligence Service · National Cyber Security Center (2025). National Network Security Framework (N2SF) Security Guideline, formal edition 1.0 (published 2025-09-30). https://www.nis.go.kr/CM/1_4/view.do?seq=373 (accessed 2026-06-24; publication date and tiered security-level system cross-checked via WebSearch). — Use: basis for the roadmap’s expansion of the scope of security conformity assessment (N2SF). ↩

D6. Presidential Committee on Digital Platform Government (2024). Government Announces ‘SW Supply Chain Security Guideline 1.0’ (press release, 2024-05-13). https://www.dpg.go.kr/DPG/contents/DPG02020000.do?schM=view&id=20240513105420991857&schBcid=press (accessed 2026-06-24; the announcement date of 2024-05-13 and the text’s plan for “preparing a roadmap through a government-wide joint task force in the second half of the year” cross-checked via WebSearch). — Use: primary announcement of the background to Guideline 1.0’s release and the “plan to prepare a roadmap through a second-half joint task force.” ↩

Original Sources of Statistics Cited by the Roadmap

E4. Cybersecurity Ventures (2024). Software Supply Chain Attacks To Cost The World $60 Billion By 2025. https://cybersecurityventures.com/software-supply-chain-attacks-to-cost-the-world-60-billion-by-2025/ (accessed 2026-06-24; the $46 billion figure for 2023 and $138 billion for 2031 confirmed via WebSearch). — Use: the actual original source of the roadmap’s supply chain damage statistic. The roadmap’s attribution to “Gartner (‘24.6)” is inaccurate and is corrected here to Cybersecurity Ventures. ↩

E6. MITRE / CISA (2025). Background on the CVE program’s contract expiration and extension. Cybersecurity Dive (2025-04): https://www.cybersecuritydive.com/news/cisa-extend-funding-cve/745531/ (accessed 2026-06-24; the $57.8 million contract, 2025-04-16 expiration, 11-month extension, and the founding of the CVE Foundation confirmed via WebSearch). Program site: https://www.cve.org/. — Use: background for the roadmap’s task of finding an alternative to the CVE program. Supplementary press source. ↩

News and Industry Coverage

B-news-etnews. ETNews (2025-12-24). Ministry of Science and ICT and National Intelligence Service Join Hands on SW Supply Chain Security… Build Government-Wide Cooperation Framework. https://www.etnews.com/20251224000334 (accessed 2026-06-24). — Use: confirms the timing of the government-wide cooperation agreement (2025-12-24). ↩

B-news-zdnet. ZDNet Korea (2026-06-16). Government to Release SW Supply Chain Security Roadmap on the 24th. https://zdnet.co.kr/view/?no=20260616111556 (accessed 2026-06-24). — Use: primary confirmation of the announcement date (2026-06-24), the responsible bodies (Ministry of Science and ICT, National Intelligence Service), the location (aT Center, Yangjae), and the 2027 institutionalization target. ↩

D-news-boan. Boannews (2026). From NIS Security Conformity Assessment to N2SF… What’s Changed in the Paradigm?. https://m.boannews.com/html/detail.html?tab_type=1&idx=140209 (accessed 2026-06-24). — Use: coverage of the transition from security conformity assessment to N2SF and its incorporation into the 2026 cybersecurity assessment. ↩

F-news-cso. CSO Online (2026). CVE program funding secured, easing fears of repeat crisis. https://www.csoonline.com/article/4142600/cve-program-funding-secured-easing-fears-of-repeat-crisis.html (accessed 2026-06-24). — Use: confirms the CVE Board’s January 21, 2026 statement of “no March funding cliff.” ↩

Development-Field Trends

H1. Black Duck (2025). Balancing AI Usage and Risk in 2025: The Global State of DevSecOps (October 2025). The survey was conducted by Censuswide among 1,001 professionals worldwide in July–August 2025. — Use: the security automation gap in the development field (45.56% still handled manually). ↩

4 - G7 "Software Bill of Materials for AI — Minimum Elements": AI Supply Chain Transparency Guidance by Cluster and Element

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

1. Overview

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

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

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

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

2. Core Content: The Seven Clusters and Elements

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

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

2.1 Metadata: The Record of the SBOM Itself

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

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

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

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

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

2.3 Models: How the Weights Were Made

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

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

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

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

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

2.4 Datasets Properties (DP): Provenance and Sensitivity

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

2.5 Infrastructure: The Link to HBOM

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

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

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

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

3. Background and Context

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

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

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

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

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

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

4. Recent Developments and Verification Challenges

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

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

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

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

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

5. Implications for Korean Readers

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

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

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

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

6. Relationship to Other Reports in This Workspace

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

7. References

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

Legislation and Regulation (Primary)

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

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

Standards and Specifications (Primary) ↩

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 - OpenChain AI SBOM Compliance Management Guide: Minimum Requirements for an AI Supply Chain Compliance Program

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

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

1. Document Overview

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

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

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

2. Background: Extending the OpenChain Methodology to AI

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

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

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

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

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

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

3. Structure and Requirements of the Guide

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

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

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

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

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

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

4. Regulatory and Governance Trends

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

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

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

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

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

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

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

5. Significance and Limitations

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

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

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

6. Process Requirements and Data Item Requirements

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

References

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

A. Primary Source and OpenChain/Standards

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

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

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

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

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

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

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

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

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

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

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

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

B. AI BOM Formats

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

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

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

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

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

C. Regulation and Governance

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

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

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

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

D. SBOM Policy Background

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

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

E. Supplementary (Academic/Industry)

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

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

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

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

6 - What the US AI Executive Order (2026-06-02) Means for Corporate Open Source Managers

Summary

The executive order “Promoting Advanced Artificial Intelligence Innovation and Security,” signed on June 2, 2026, imposes no obligations on companies. Its core is the Treasury Department-led AI Cybersecurity Clearinghouse (a relay body that gathers, verifies, and distributes vulnerability information in one place, to be formed within 30 days) and a voluntary pre-sharing framework for frontier models (to be designed within 60 days); mandatory licensing and pre-approval are explicitly excluded A1. No provision applies directly to corporate open source managers either. Still, the order is worth reading because of what lies behind it. AI finding open source vulnerabilities faster than humans is already a reality. Before the order, Anthropic’s unreleased model found 6,202 high- or critical-severity vulnerabilities in open source projects over two months, and patching has not kept pace A6·C1. What open source managers need to prepare for is not executive-order compliance but a response system that can handle a patch-processing capacity check, EOL component cleanup, and the EU Cyber Resilience Act reporting obligations that take effect September 11, 2026 — all at once.

1. What the Executive Order Actually Establishes

The executive order consists of five sections, all premised on voluntary cooperation. Section 1 declares a stance of “refusing to stifle innovation through excessive regulation” and an America First approach to cybersecurity, while Section 5 contains standard general provisions. The substantive content sits in the three middle sections A1.

Section 2 addresses strengthening federal and private-sector cyber defense. Within 30 days, it prioritizes defense of national security systems, Department of War systems, and federal civilian systems, and on the same timeline the Treasury Secretary, in consultation with the National Cyber Director, the National Security Agency (NSA), and the Cybersecurity and Infrastructure Security Agency (CISA), forms the AI cybersecurity clearinghouse. A clearinghouse originally refers to an interbank institution for clearing checks — a relay body that gathers, verifies, and distributes information from multiple participants in one place. Here, it takes on the role of coordinating software vulnerability scanning through voluntary cooperation with the AI industry and critical infrastructure operators to eliminate duplication, discovering and verifying vulnerabilities, and prioritizing the fixing and distribution of patches A1.

Section 3 addresses the safe deployment of frontier models. Within 60 days, it establishes a classified benchmarking procedure to assess AI models’ cyberattack capabilities, and the NSA Director determines, based on those results, the threshold for which models qualify as “covered frontier models.” Through a voluntary framework, developers consult with the government on whether their models meet the designated criteria, provide the government with model access up to 30 days before the planned public release date, and jointly select trusted partners who will receive early access. Sec. 3(c) explicitly states that nothing in this section establishes mandatory licensing, pre-approval, or permitting requirements for the development, publication, disclosure, or deployment of new AI models A1.

Section 4 addresses investigation and enforcement. The Attorney General prioritizes enforcement of existing federal criminal law — including 18 U.S.C. 1030 (Computer Fraud and Abuse Act) — against unauthorized computer access and damage carried out using AI, and other crimes committed in the process A1.

Figure 1. Policy timeline before and after the executive order (source: official White House documents)

Observers describe the choice of lead agency as unexpected. Given that vulnerability coordination is the function at stake, it would seem natural for CISA or the Office of the National Cyber Director to lead, yet the clearinghouse is led by the Treasury Department. The Council on Foreign Relations (CFR) suggested this may be because Treasury is “one of the few agencies with institutional capacity remaining,” while the Atlantic Council flagged the risk of overlap with existing vulnerability coordination frameworks B4·B5. The key term “covered frontier model” is also left undefined in the text. It will be determined as a result of the classified benchmarking, and WilmerHale expects this definition to be the focus of agency rulemaking over the coming months B2.

2. Why Now

The direct backdrop to the executive order is Claude Mythos Preview, which Anthropic announced on April 7, 2026. This unreleased model scored 83.1% on the vulnerability-reproduction benchmark CyberGym (up from 66.6% for the prior model), and rather than a general release, Anthropic chose Project Glasswing, opening access only to 12 partners including AWS, Apple, Google, and Microsoft A6. In under two months, participating organizations identified more than 10,000 high- or critical-severity vulnerabilities. Anthropic’s own scans alone turned up 23,019 issues across more than 1,000 open source projects, of which 6,202 were high or critical severity, and an independent security firm verified a sample of 1,752 and confirmed that more than 90% were genuine vulnerabilities C1·C2. Notable examples include a remote crash flaw that had lain dormant in OpenBSD for 27 years, a 16-year-old flaw in FFmpeg that had survived 5 million automated tests, and a privilege-escalation chain in the Linux kernel A6.

This process revealed a sharp mismatch between the speed of finding vulnerabilities and the speed of fixing them. Anthropic itself stated that “the bottleneck to fixing these bugs is human capacity to triage, report, and design and ship patches,” and as open source maintainers became that bottleneck, it began collaborating with OpenSSF’s Alpha-Omega project C1·C2. Bruce Schneier assessed that, for now, “discovery for fixing” remains easier than “discovery for exploitation,” opening a window favorable to defenders — but that this window is temporary, and an era of automated zero-day discovery will arrive before we finish preparing for it. He also noted, citing the security firm Aisle’s reproduction of some results with older, publicly available models, that this capability is not the exclusive property of any one company C3.

The executive order is the US government’s response to this situation. The clearinghouse is the government’s plan to coordinate at a national level what had been done individually in the private sector, as with Glasswing — using AI to find and verify vulnerabilities and coordinate patches A1·B5.

3. What This Means for Corporate Open Source Managers

3.1 A Document That Never Says “Open Source”

Neither the executive order’s text nor the White House fact sheet contains the phrase “open source” anywhere A1·A2. Viewed favorably, this means there is no regulatory burden. The order imposes no obligations on open source developers or open-weight model distributors, and Sec. 3(c)’s prohibition on licensing covers “development, publication, disclosure, or deployment” of models broadly, so distribution via open weights also falls within its protection A1. The administration’s official stance is consistent with what was stated in the July 2025 AI Action Plan: the choice between open and closed rests entirely with the developer, and the federal government will foster an environment favorable to open models A5.

What remains an open question is the threshold for covered frontier models. Because it is determined through a classified benchmark, it is currently impossible to know what happens if an open-weight model exceeds that threshold. The core mechanism of the voluntary framework — “government access 30 days before release” — is designed for closed models whose release timing can be controlled, and this approach does not translate to open models, whose weights, once released, cannot be recalled. CFR experts have suggested that frontier-level vulnerability-reasoning capability will likely be reproduced in open-weight systems before long, and similar reproduction studies are already being mentioned B5. If the capability spreads to open models, the gap in the voluntary pre-sharing design will become apparent, and further regulatory discussion could then target open models. Companies that internally adopt or fine-tune and deploy open-weight models should watch how the benchmarking procedure and subsequent rulemaking, due by August 1, treat open models.

Open source foundations have also stayed quiet so far. As of the search conducted on 2026-06-10, no statement from the Open Source Initiative (OSI), the Linux Foundation, or OpenSSF regarding this executive order could be found. With no obligations imposed, the incentive to respond immediately appears to have been weak. The closest official position is OSI’s response to the 2025 AI Action Plan public comment period, submitted in March 2025 B7.

3.2 Where the Clearinghouse Meets Corporate Vulnerability Management

The clearinghouse’s three functions — coordinating scans, discovering and verifying vulnerabilities, and prioritizing patch deployment — overlap precisely with the vulnerability management systems that corporate open source organizations (OSPOs or product security teams) already operate A1.

Figure 2. Where the corporate open source manager sits in the clearinghouse and vulnerability information flow (source: Executive Order Sec. 2(d))

Most companies will encounter the clearinghouse as information consumers. Once it is operational, discovery, verification, and patch-priority information for open source component vulnerabilities will flow through a new channel. This effectively adds a US-originated channel to a company’s vulnerability intelligence pipeline and adds a coordinating body that influences patch-priority decisions.

Whether to participate directly in the clearinghouse is a separate decision. Companies in critical infrastructure sectors (energy, finance, healthcare, telecommunications, and the like) are explicitly named as intended participants A1. Participation brings early access to vulnerability information, a voice in patch coordination, and access to the government-supported security tools mentioned in Sec. 2(c)(iii). In exchange, participants take on the legal-review burden that comes with information sharing, and, as Crowell & Moring pointed out, face the uncertainty that liability protection for participants is not specified and the consequences of non-participation are not defined either B3. As WilmerHale anticipates, if the voluntary provisions migrate into federal procurement standards, there is a scenario where participation becomes a de facto precondition for companies doing business with the US government B2. There is no reason to rush a decision before the operational details are published in early July.

3.3 The Most Direct Impact: A Surge in Patch Demand and EOL Risk

Changes already underway independent of the executive order are now being accelerated by it. As AI-driven discovery becomes institutionalized at the national level, backed by federal funding (Sec. 2(e)), the volume of reported vulnerabilities in open source components can only grow. The Glasswing figures gave an early preview of that scale.

The first thing companies run into is throughput. As new CVEs multiply across the open source components in a company’s own products, triage (impact analysis), patch application, and customer communication must scale up together. Organizations relying on manual triage will be the first to accumulate a backlog.

EOL (End-of-Life) components present a deeper problem. AI scans code indiscriminately, whether or not it is still maintained, but patches require a maintainer. As HeroDevs, a commercial long-term support (LTS) vendor, has pointed out, the gap between discovery speed and fix speed opens widest in EOL software. If components remain in inventory for which discovery is accelerating while a fix will never arrive, that risk only grows over time C4. The 27-year-old OpenBSD flaw and the 16-year-old FFmpeg flaw show that the assumption that older, stable components are safer no longer holds A6.

Pressure on the upstream side ultimately becomes the company’s own risk. Anthropic itself confirmed that open source maintainers are becoming the bottleneck in the flood of reports C2. When the maintainer of a core component a company depends on is overwhelmed with triage, it is the company that bears the resulting patch delay. Adding upstream maintenance health (maintainer count, security-response track record, foundation affiliation) as an evaluation criterion for core dependencies, and participating in upstream support such as Alpha-Omega where needed, is a path to reducing that risk.

3.4 Contrast with the EU CRA: Handling Voluntary and Mandatory Regimes at Once

The problem the US clearinghouse addresses — discovering and patching software vulnerabilities — is the same area the EU has made mandatory through the Cyber Resilience Act (CRA — Regulation (EU) 2024/2847).

Table 1. Comparison of US executive order and EU CRA vulnerability reporting regimes (sources: original text of the executive order A1, Regulation (EU) 2024/2847 A7, separate report D1. As of 2026-06-10)

For Korean companies shipping products into both markets, the priority is clear. Whichever regime carries binding force, deadlines, and fines comes first. The CRA Article 14 reporting workflow must be operational by September 11, three months from now, and it has already been confirmed that, because ENISA does not currently offer an SRP integration API, the workflow must be designed as a manual, human-submitted process A7·D1. The US clearinghouse comes next. Still, both regimes run on the same underlying internal capabilities — a component inventory (SBOM), vulnerability triage, a Coordinated Vulnerability Disclosure (CVD) intake channel, and a patch deployment process. A system built to prepare for the CRA becomes the foundation for voluntary participation on the US side, so there is no need to build a separate system twice.

3.5 Policy Divergence: US Voluntary Cooperation, EU Institutionalization

The day after the executive order, on June 3, the European Commission published its Tech Sovereignty package, placing open source at the center of digital policy. Its core elements are mobilizing roughly €2 billion in public and private funding over seven years, establishing an Open Source Maintenance Instrument, and opening up public procurement A8·D2. The two documents, published a day apart, reveal contrasting institutional designs for the same technological landscape. The US model excludes regulation and has government coordinate the private sector’s voluntary capacity; the EU model institutionalizes the open source ecosystem itself through public funding and legal obligation (including the CRA’s steward regime).

Global companies’ open source management policy needs to be built with this divergence as a given. In the US market, they must decide whether to enter the voluntary cooperation channel; in the EU market, they must respond to the obligations of CRA compliance and the steward regime. Since the same team within a company will end up operating both modes, it is more realistic to build market-specific modules on top of shared capabilities than to keep policy documents and response organizations separated by market.

3.6 A Different Axis from AI-Generated Code Management

A separate analysis addressing the inflow of AI-generated code into open source and snippet inspection D3 and this matter both sit at the intersection of AI and open source management, but along different axes. That analysis addressed inflow management — the licensing and provenance problems that arise when AI coding tools bring code fragments not declared as packages into a codebase. What this executive order points to is operations — the response problem in an environment where vulnerabilities in open source components already present in the codebase are being surfaced faster and in greater volume because of AI. AI is now affecting both the stage where code enters and the stage where vulnerabilities surface, and the response systems for both axes need to be checked separately.

4. What to Prepare

Since the executive order makes no direct demands of companies, preparation splits into what to do now and what to watch.

What to Do Now

The starting point is an inventory of your own AI exposure surface. Bring together, in one place, the models you develop or fine-tune internally (especially open-weight-based ones), the AI coding and security tools you’ve adopted, and the current state of AI-generated code that has entered your codebase. This puts you in a position to judge quickly, once the covered-frontier-model criteria take shape after August 1, whether your company falls near that boundary.

Also review your open source vulnerability response system. Check whether SBOMs are current across all products, whether new-CVE triage can absorb a two- to three-fold increase in volume, and whether the CVD intake channel is functioning. This review is the same work as preparing for CRA Article 14 (deadline September 11), so there is no need to spin up a separate project — fold it into CRA preparation D1.

The most urgent item is cleaning up EOL components. Identify end-of-maintenance components in your SBOM, set a schedule for those with an upgrade path, and for those that cannot be removed immediately, arrange a patch source such as commercial LTS or in-house patching. For items where you can demonstrate no impact, document them using Vulnerability Exploitability eXchange (VEX) to reduce the triage burden C4.

Finally, assess the health of critical upstream dependencies. Check the maintainer base size and security-response track record of the upper-level components that your revenue-critical products depend on, and consider support measures such as sponsorship or contribution for projects where a bottleneck is a concern C2.

What to Watch

Table 2. Items to track and their timing (as of 2026-06-10)

5. Conclusion

This executive order imposes no new obligations on corporate open source managers, but it is a signal that the premises of the operating environment are shifting. An era in which AI finds open source vulnerabilities in bulk has been demonstrated, and the US government has decided to institutionalize that trend through coordination rather than regulation. Discovery is accelerating while patching still moves at human speed. The only thing companies can control in this gap is the processing capacity of their own inventory. Because the EU CRA reporting obligation taking effect three months from now requires SBOM, triage, and CVD capabilities regardless, preparing for both markets with a single system is the most efficient path. As for the executive order itself, only two dates need to go on the calendar: July 2 (clearinghouse) and August 1 (benchmarking criteria).

References

All URLs were confirmed accessible and matching their cited content on 2026-06-10 (except where noted otherwise).

A. Primary Sources (Official Government Documents, Direct-Party Statements)

A1. The White House (2026). Promoting Advanced Artificial Intelligence Innovation and Security (Executive Order). Signed 2026-06-02. https://www.whitehouse.gov/presidential-actions/2026/06/promoting-advanced-artificial-intelligence-innovation-and-security/ (accessed: 2026-06-10). — The primary source for this report. ↩

A2. The White House (2026). Fact Sheet: President Donald J. Trump Promotes Advanced Artificial Intelligence Innovation and Security. 2026-06-02. https://www.whitehouse.gov/fact-sheets/2026/06/fact-sheet-president-donald-j-trump-promotes-advanced-artificial-intelligence-innovation-and-security/ (accessed: 2026-06-10). ↩

A3. The White House (2026). National Security Presidential Memorandum/NSPM-11 — Artificial Intelligence in the National Security Enterprise. 2026-06-05. https://www.whitehouse.gov/presidential-actions/2026/06/national-security-presidential-memorandum-nspm-11/ (accessed: 2026-06-10). ↩

A4. The White House (2025). Removing Barriers to American Leadership in Artificial Intelligence (Executive Order 14179). 2025-01-23. https://www.whitehouse.gov/presidential-actions/2025/01/removing-barriers-to-american-leadership-in-artificial-intelligence/ (accessed: 2026-06-10). ↩

A5. The White House (2025). Winning the Race: America’s AI Action Plan. 2025-07. https://www.whitehouse.gov/wp-content/uploads/2025/07/Americas-AI-Action-Plan.pdf (accessed: 2026-06-10, passage confirmed directly against the PDF original). ↩

A6. Anthropic (2026). Project Glasswing: Securing critical software for the AI era. Announced 2026-04-07 (subsequently updated). https://www.anthropic.com/glasswing (accessed: 2026-06-10). ↩

A7. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed: 2026-05-12, confirmed during verification of this workspace’s CRA report). ↩

A8. European Commission (2026). Communication on European Tech Sovereignty, accompanied by an EU Open Source Strategy. COM(2026) 503 final, 2026-06-03. https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy (accessed: 2026-06-10). ↩

B. Legal and Policy Analysis

B1. Wiley Rein LLP (2026). New AI Executive Order Addresses Frontier Models and Cybersecurity Vulnerabilities. https://www.wiley.law/alert-New-AI-Executive-Order-Addresses-Frontier-Models-and-Cybersecurity-Vulnerabilities (accessed: 2026-06-10). ↩

B2. WilmerHale (2026). New Executive Order Addressing Early Government Access to Frontier AI Models. 2026-06-02. https://www.wilmerhale.com/en/insights/client-alerts/20260602-new-executive-order-addressing-early-government-access-to-frontier-ai-models (accessed: 2026-06-10). ↩

B3. Crowell & Moring LLP (2026). Executive Order Creates Voluntary Regulatory Regime of Frontier AI Models. https://www.crowell.com/en/insights/client-alerts/executive-order-creates-voluntary-regulatory-regime-of-frontier-ai-models (accessed: 2026-06-10). ↩

B4. Atlantic Council (2026). Reading between the lines of Trump’s new executive order on AI. https://www.atlanticcouncil.org/dispatches/reading-between-the-lines-of-trumps-new-executive-order-on-ai/ (accessed: 2026-06-10). ↩

B5. Council on Foreign Relations (2026). Assessing Trump’s Executive Order on AI Oversight. https://www.cfr.org/articles/assessing-trumps-executive-order-on-ai-oversight (accessed: 2026-06-10). ↩

B6. CSO Online (2026). OpenAI responds to White House executive order on AI governance. https://www.csoonline.com/article/4181294/openai-responds-to-white-house-executive-order-on-ai-governance.html (accessed: 2026-06-10).

B7. Open Source Initiative (2025). OSI and Apereo Foundation Respond to White House on AI Action Plan. https://opensource.org/blog/osi-and-apereo-foundation-respond-to-white-house-on-ai-action-plan (accessed: 2026-06-10). ↩

C. Industry and Security Community

C1. CyberScoop (2026). Anthropic expanding access to Project Glasswing. 2026-06-02. https://cyberscoop.com/anthropic-project-glasswing-expansion-critical-infrastructure-claude-mythos/ (accessed: 2026-06-10). ↩

C2. Help Net Security (2026). Anthropic: Claude Mythos identified 10,000+ software flaws. 2026-05-26. https://www.helpnetsecurity.com/2026/05/26/anthropic-project-glasswing-update/ (accessed: 2026-06-10). ↩

C3. Schneier, Bruce (2026). On Anthropic’s Mythos Preview and Project Glasswing. Schneier on Security, 2026-04. https://www.schneier.com/blog/archives/2026/04/on-anthropics-mythos-preview-and-project-glasswing.html (accessed: 2026-06-10). ↩

C4. HeroDevs (2026). AI Cybersecurity Executive Order 2026: What It Means for EOL Software. https://www.herodevs.com/blog-posts/ai-cybersecurity-executive-order-2026-what-it-means-for-eol-software (accessed: 2026-06-10). — Cited with awareness of the vendor’s commercial-LTS interest. ↩

D. Related Analysis (This Blog)

D1. EU Cyber Resilience Act (CRA) Vulnerability Reporting Obligations — Preparing for the 2026-09-11 Effective Date (updated 2026-06-09). ↩

D2. EU Open Source Strategy: Institutionalizing Open Source for Tech Sovereignty (2026-06-05). ↩

D3. AI-Generated Code: How Far Should Open Source Inspection Go (2026-06-08). ↩

7 - EU Open Source Strategy: Institutionalizing Open Source for Technological Sovereignty

Summary

The Communication on European Tech Sovereignty (COM(2026) 503 final), published by the European Commission on June 3, 2026, comes with an attached EU Open Source Strategy. It is the first instance of placing open source at the center of EU digital policy. The strategy sets four goals — leveraging open source for sovereignty, strengthening the ecosystem, opening up public administration, and standards and international cooperation — and calls for the public and private sectors to mobilize approximately €2 billion for open-source-related measures over the next seven years. The aim is to reduce the EU’s dependency structure, under which it spends €264 billion annually on proprietary IT from the United States. Civil society (FSFE) and policy analysts welcomed the direction while pointing to limitations in funding adequacy, the relationship between open standards and open source, the neglect of open hardware, and the practitioner skills gap. For Korean public and corporate practitioners, the opening of EU procurement, open source steward regulation, and the open-source default for the EUDI Wallet are the points to watch directly.

1. Overview

The European Commission announced the technological sovereignty package in Brussels on June 3, 2026. A Communication is not binding legislation but a document that sets out the Commission’s policy direction and planned follow-up actions.A1·A2 The package consists of four interconnected initiatives: Chips Act 2.0 for semiconductors, the Cloud and AI Development Act (CADA), the Open Source Strategy, and a roadmap for energy sector digitalization and AI. The scope of this report is the Open Source Strategy (Chapter 4 of the COM document).A1

The problem the strategy seeks to address is clear. The Draghi Report noted that the EU depends on non-EU suppliers for more than 80% of its digital products and services, infrastructure, and intellectual property.A1 The Open Source Strategy chose open source as the means to reduce this dependency. Europe, the birthplace of Linux, has more than 3 million open source contributors, and nearly half of code commits come from small companies with fewer than 50 employees. The assets exist, but they face structural limitations in scaling and funding.A1

2. Key Content: Four Goals

The strategy combines two tracks of measures: supply-side measures that help EU communities and companies develop and maintain high-quality open source components, and demand-side measures that accelerate adoption in the private and public sectors. It bundles public funding together with market- and demand-driven measures, and was built on more than 1,600 responses received through the Commission’s call for evidence.A1·B3

Figure 1. The four goals of the Open Source Strategy and their representative measures (Source: COM(2026) 503 final, Chapter 4, 2026-06-03)

Leveraging open source for technological sovereignty (Goal i). The Commission is expanding the Open Internet Stack into a shared catalogue of European open source building blocks, and has mobilized €41.3 million through three calls under the Horizon Europe 2026–2027 work programme.A1 Making the EU digital identity ecosystem open source is a central pillar. The EU Digital Identity Regulation (EUDIR) sets a legal default requiring the EUDI Wallet application components to be open source; building on this, the reference implementations of the Identity Wallet (EUID) and the European Business Wallet (EBW) are being developed as open source, with their long-term stewardship transferred to the European Digital Public Infrastructure Foundation.A1 The Commission cooperates with member states through the European Digital Infrastructure Consortium (EDIC) on Digital Commons, and aims to reach 30 million active users of open source collaboration and productivity tools and secure email by 2030.A1

Strengthening the ecosystem (Goal ii). Open source building blocks are mostly maintained through foundations, and most of the funding comes from US and Chinese Big Tech.A1 The open source software steward concept introduced by the Cyber Resilience Act (CRA) is the regulatory pillar of this goal. The Commission is developing a stewardship toolkit to help establish foundations, and supports the establishment of a European Digital Public Infrastructure steward organization that governs EU-funded strategic assets from a single hub. To maintain and secure key components, it is creating a new Open Source Maintenance Instrument, building European capacity to fork projects when needed.A1

Opening up public administration (Goal iii). The “public money, public code” principle has been explicitly written into the strategy.A1·B2 The Commission already operates a Matrix-based communication platform, the openDesk collaboration environment, and Drupal across more than 300 europa.eu sites.A1 In procurement, it is revising tender guidelines so that open source can compete with proprietary solutions, and strengthening the Open Source Programme Office (OSPO) and the EU Public Sector OSPO Network as central hubs.A1·B2

Standards and international cooperation (Goal iv). In the revision of the EU Standardisation Regulation, the Commission is improving cooperation between open source and standardization communities, and providing conditions for specific standards to be implemented as open source. Through the Team Europe approach, EU open source solutions are being deployed to enlargement and partner countries.A1

Governance Structure

Rather than creating new bodies, the strategy weaves together existing governance assets. Three pillars interlock.

Figure 2. How the governance bodies of the Open Source Strategy connect (Source: COM(2026) 503 final, Chapter 4 and Annex II, 2026-06-03)

The Commission’s OSPO (established 2020) and the EU Public Sector OSPO Network, with 25 members from 11 countries, handle the public administration pillar, while the Digital Commons EDIC, established on October 29, 2025, handles the multi-country cooperation pillar.A1·A5 Both converge into the European Digital Public Infrastructure Foundation, currently being established, which will take on long-term stewardship of strategic assets such as EUID and EBW.A1

3. Background and Context

The Open Source Strategy is not a standalone regulation but a policy umbrella layered on top of several pieces of EU legislation. The Interoperable Europe Act (Regulation (EU) 2024/903) defines “open source licence” and underpins public sector reuse,A4 while the CRA (Regulation (EU) 2024/2847) provides the steward regulatory category and voluntary security attestation (Article 25).A3 The AI Act places proportionate obligations on free and open source models, and the EUDIR sets the open-source default for the EUDI Wallet.A1·C1

The watershed in this policy lineage was 2020. The Commission adopted the Open Source Software Strategy 2020–2023 (C(2020) 7149 final) on October 21, 2020, introducing a “think open” culture, and established the Commission’s OSPO as its first action.A5 Since then, code.europa.eu (4,500 users and 1,280 repositories as of May 2026) and the EU Open Source Solutions Catalogue (launched March 2025, 1,047 solutions) have been built.A1 The new strategy explicitly cites these as its foundation.

The “public money, public code” principle originated in a campaign launched by the Free Software Foundation Europe (FSFE) in 2017. The strategy adopted this principle nine years after the campaign began.B4

4. Recent Developments and Timeline

As the announcement was only days ago, developments center on the immediate reactions and the procedures scheduled ahead.

Figure 3. Rollout timeline of the EU Open Source Strategy (Source: COM(2026) 503 final and Commission announcements, as of 2026-06-05)

On the day of the announcement, FSFE issued a cautious welcome. While welcoming the adoption of the “Public Money? Public Code!” principle, Johannes Näder said “the Commission still falls short on concrete goals, milestones, and secured funding,” and Lucas Lasota stated that “implementation is now what matters, and it will require secured long-term funding, meaningful civil society participation, and effective enforcement of the Digital Markets Act."B4

A policy analysis by TechPolicy.Press (Gates, Givropoulou, Karhu, 2026-06-03) assessed the strategy as “Europe’s most meaningful progress yet” while pointing to four gaps.E1 The precedence between open standards and open source remains unsettled, treatment of open hardware is limited to RISC-V and EDA tools, the €2 billion over seven years is insufficient against the €264 billion in annual dependency, and development of practitioner-level contribution, maintenance, and governance capacity remains weak. The law firm Covington also summarized the package’s investment scale and corporate impact on June 4, 2026.E3

The nature of the funding adds to the uncertainty. The €2 billion is not a firmly allocated budget but an aggregate estimate of what the public and private sectors “should mobilize” over seven years.A1 The Open Source Maintenance Instrument, the European Digital Public Infrastructure Foundation, and the voluntary EU assessment framework are all still at the stage of a “we will create” commitment, with no concrete design or amount yet determined.

On the schedule ahead, the package will be reflected in member states’ revisions of their national Digital Decade strategic roadmaps in December 2026, and the proposed revision of the Standardisation Regulation and the legislative processes for CADA and Chips Act 2.0 will flesh out the open source requirements. The Commission discusses progress annually at the Digital Decade Board and reports to the European Parliament every three years.A1

5. Implications and Considerations

This strategy does not apply directly to Korean public agencies and companies, but there are several points worth watching in practice.

The opening of EU public procurement is the most concrete variable. If tender specifications come to include open standards and models, and open source is put in a position to compete with proprietary solutions, Korean software vendors seeking to enter the EU public market will benefit from open-source-friendly proposals and clear licensing.A1·B2 Conversely, this opens up EU procurement opportunities for Korean companies with open-source-based businesses.

Open source steward regulation is a point that companies launching CRA-covered products in the EU need to examine. Security attestation for products relying on open source components (CRA Article 25) and the scope of steward responsibility are expected to be fleshed out through the strategy’s voluntary EU assessment framework, so it is prudent to put a Software Bill of Materials (SBOM) and dependency management framework in place in advance.A1·A3 That the EUDI Wallet and the European Business Wallet default to open source reference implementations is something Korean fintech and authentication providers considering EU digital identity integration should watch.A1

From the perspective of Korean public software policy, the institutionalization path of the “public money, public code” principle and the OSPO Network governance model offer a useful reference. However, since the EU itself has left funding adequacy and practitioner capacity as unresolved challenges, the gap between declaration and implementation also bears watching.B4·E1

6. References

A. Primary Legal and Regulatory Texts

A1. European Commission (2026). Communication from the Commission on European Tech Sovereignty, accompanied by an EU Open Source Strategy. COM(2026) 503 final, Brussels, 3.6.2026 (main text and ANNEXES 1–2). Primary source for this report. sources/COM-2026-503-eu-tech-sovereignty.pdf and …-annexes.pdf. Download: https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy (accessed: 2026-06-05). ↩

A2. European Commission (2026). Strengthening Europe’s tech sovereignty (press release). 2026-06-03. https://commission.europa.eu/news-and-media/news/strengthening-europes-tech-sovereignty-2026-06-03_en (accessed: 2026-06-05). ↩

A3. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal, OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed: 2026-06-05). ↩

A4. European Parliament and Council (2024). Regulation (EU) 2024/903 — Interoperable Europe Act. Official Journal, OJ L, 2024/903, 22.3.2024. https://eur-lex.europa.eu/eli/reg/2024/903/oj/eng (accessed: 2026-06-05). ↩

A5. European Commission (2020). Open Source Software Strategy 2020–2023. C(2020) 7149 final, Brussels, 21.10.2020. https://commission.europa.eu/system/files/2023-02/en_ec_open_source_strategy_2020-2023.pdf (accessed: 2026-06-05). ↩

B. Official Documents and Policy Pages from Issuing Bodies

B1. European Commission — Shaping Europe’s digital future (2026). The EU Open Source Strategy (policy page). Updated 2026-06-03. https://digital-strategy.ec.europa.eu/en/policies/open-source-strategy (accessed: 2026-06-05).

B2. European Commission (2026). Commission boosts open and interoperable digital ecosystems for public administrations (press release). 2026-06-03. https://commission.europa.eu/news-and-media/news/commission-boosts-open-and-interoperable-digital-ecosystems-public-administrations-2026-06-03_en (accessed: 2026-06-05). ↩

B3. European Commission — Shaping Europe’s digital future (2026). Commission opens call for evidence on Open-Source Digital Ecosystems. 2026-01-12 (deadline 2026-02-03). https://digital-strategy.ec.europa.eu/en/news/commission-opens-call-evidence-open-source-digital-ecosystems (accessed: 2026-06-05). ↩

B4. Free Software Foundation Europe (2026). EU Tech Sovereignty: A milestone for Public Code? Now implementation is key. 2026-06-03. https://fsfe.org/news/2026/news-20260603-01.en.html (accessed: 2026-06-05). ↩

C. Standards and Frameworks

C1. European Commission (2024). Regulation (EU) 2024/1689 — Artificial Intelligence Act. Official Journal, OJ L, 2024/1689, 12.7.2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng (accessed: 2026-06-05). ↩

C2. European Parliament and Council (2023). Regulation (EU) 2023/2854 — Data Act. Official Journal, OJ L, 2023/2854, 22.12.2023. https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng (accessed: 2026-06-05).

D. Academic and Policy Research

D1. Blind, K. et al. (2021). The impact of Open Source Software and Hardware on technological independence, competitiveness and innovation in the EU economy. European Commission. https://digital-strategy.ec.europa.eu/en/library/study-about-impact-open-source-software-and-hardware-technological-independence-competitiveness-and (accessed: 2026-06-05).

E. Industry, Law Firm, and Media Analysis (Supplementary)

E1. Gates, N., Givropoulou, A., Karhu, J. (2026). How the EU’s Tech Sovereignty Package Finally Puts Open Source to the Test. TechPolicy.Press, 2026-06-03. https://www.techpolicy.press/how-the-eus-tech-sovereignty-package-finally-puts-open-source-to-the-test/ (accessed: 2026-06-05). ↩

E2. TechPolicy.Press (2026). EU Unveils Sweeping Tech Sovereignty Push, Balancing Autonomy with Openness. 2026-06-03. https://www.techpolicy.press/eu-unveils-sweeping-tech-sovereignty-push-balancing-autonomy-with-openness/ (accessed: 2026-06-05).

E3. Covington & Burling (2026). EU Tech Sovereignty Package. Global Policy Watch, 2026-06-04. https://www.globalpolicywatch.com/2026/06/eu-tech-sovereignty-package/ (accessed: 2026-06-05). ↩

E4. Agence Europe (2026). European Commission seeks to harness open source in its tech sovereignty strategy and develop European alternatives. 2026-06. https://agenceurope.eu/en/bulletin/article/13877/4/european-commission-seeks-to-harness-open-source-in-its-tech-sovereignty-strategy-and-develop-european-alternatives (accessed: 2026-06-05).

8 - EU Cyber Resilience Act (CRA) Vulnerability Reporting Obligations — A Research Report on Preparing for the September 11, 2026 Effective Date

Summary

The EU Cyber Resilience Act (CRA — Regulation (EU) 2024/2847) is the first comprehensive product security regulation in EU history, imposing horizontal cybersecurity obligations on every “product with digital elements” (PDE) placed on the EU market. Entering into force on December 10, 2024, the Regulation applies in phases. From September 11, 2026, the Article 14 reporting obligations take effect, requiring manufacturers, importers, and distributors to notify ENISA (the European Union Agency for Cybersecurity) and member state CSIRTs of actively exploited vulnerabilities and severe security incidents within a staged 24-hour, 72-hour, and 14-day deadline structure. If a reporting workflow is not operational by this date, a company risks a fine of up to €15 million or 2.5% of worldwide annual turnover, and a Korean company becomes subject to these obligations the moment it places a product on the EU market. A1, B1, E1

1. Why September 11, 2026 Matters for Korean Companies

September 11, 2026 is the first application date for the CRA’s Article 14 reporting obligations. On the same day, ENISA’s Single Reporting Platform (SRP) also goes live. A1, B4 The CRA’s remaining essential obligations, including CE marking and conformity assessment, are due by December 11, 2027, but the reporting workflow must be in place 15 months ahead of that deadline.

The weight this date carries for Korean companies comes from the CRA’s legal character. The CRA is not a Directive that member states must transpose into national law; it is a Regulation with direct effect, applying immediately upon entry into the EU market without any separate national implementing legislation. A1 A company headquartered in Korea that exports directly to the EU without an EU legal entity does not escape coverage. It is also worth noting that legacy products — products already placed on the EU market — are covered as well. E1

As of June 2026, about three months remain before the reporting obligation takes effect. ENISA has said it will hold a testing period but has not yet released an official schedule, and it has announced that an operations manual will be provided sometime in June 2026. ENISA has also stated explicitly that, at this stage, it does not provide an API for SRP integration. B4 Companies that assumed automated integration will need to redesign their reporting process around manual submission to the platform by a human operator.

2. Structure of the CRA

2.1 Legislative Background and Entry-into-Force Timeline

The CRA’s official title is Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements. It was first announced in President Ursula von der Leyen’s State of the Union address in September 2021, and the European Commission proposed the legislative text on September 15, 2022. The European Parliament adopted it in plenary on March 12, 2024 by a vote of 517 in favor to 12 against, and the Council gave its final adoption on October 10 of the same year, followed by signature on October 23 and publication in the Official Journal of the EU on November 20. The Regulation entered into force on December 10, 2024. A1, B1

Figure 1. CRA legislative and implementation timeline (Source: Regulation (EU) 2024/2847, EC Legislative Train)

The open source community’s advocacy stood out during the legislative process. During the 2022–2023 drafting stages, the Eclipse Foundation, the Open Source Initiative (OSI), the Document Foundation, and others warned that an unclear definition of “commercial activity” could push compliance burdens onto volunteer developers. The provisional agreement of December 2023 introduced the concept of an “open-source steward” along with exemption clauses, easing some of these concerns, but the scope of coverage for small-scale redistributors remains a matter of dispute. D1

2.2 Scope of Application (Art. 2–3)

The CRA applies to “products with digital elements” (PDE). This covers hardware and software capable of logical or physical data connection to a device or network, and includes software components placed on the market independently. B3

Some products fall outside the scope. The main examples are free and open-source software supplied without commercial activity, and products already covered by stricter sector-specific cybersecurity regulation, such as medical devices or automobiles. Even so, the CRA may apply in a “complementary” capacity to products already subject to existing cybersecurity regulation, so a sector-by-sector judgment is required. A1, E2

Figure 2. CRA scope determination flow (Source: CRA Art. 2–3, Implementing Regulation (EU) 2025/2392)

2.3 Phased Application

Full application of the CRA does not occur at a single point in time.

A1, B3

What must be in place by September 11, 2026 is not product certification but a vulnerability and incident reporting workflow. The deadline for CE marking and conformity assessment is 15 months later, on December 11, 2027.

3. Manufacturer Obligations (Art. 13)

3.1 Annex I Essential Requirements

Article 13 requires manufacturers to meet the essential cybersecurity requirements set out in CRA Annex I. These requirements fall into two broad groups. A1, B3

Part I — Product security requirements: placed on the market without known exploitable vulnerabilities, no default passwords, provision of security updates, application of the principle of least privilege, data protection, minimization of attack surfaces, resilience-by-design, and provision of records of access to and modification of personal data.

Part II — Vulnerability handling requirements: identifying and documenting vulnerabilities, maintaining an SBOM, providing patches promptly and distributing them free of charge, a Coordinated Vulnerability Disclosure (CVD) policy, reporting of exploited vulnerabilities and incidents (Art. 14), and monitoring for vulnerabilities across the full product lifecycle.

No harmonized standards for these requirements have been finalized yet, so manufacturers must implement them directly against the functional requirements in the CRA text itself. The CRA Requirements Standards Mapping (2024), jointly published by ENISA and the JRC, maps these requirements to existing standards, with ISO/IEC 30111 (vulnerability handling), ISO/IEC 29147 (vulnerability disclosure), and NIST SP 800-218 (SSDF) serving as the main reference points. B5, C1, C2, C6

3.2 Support Period

Manufacturers must provide security support for the product’s expected lifetime after it is placed on the market, for a minimum of five years. For products with an expected lifetime of less than five years, that shorter period may serve as the support period. The support period must be stated explicitly on the product, and vulnerability handling and the provision of security updates are mandatory throughout it. A1, B3

3.3 SBOM Requirements

CRA Annex I Part II mandates a Software Bill of Materials (SBOM). Manufacturers must generate an SBOM for every released version and keep it in a machine-readable format, ready for requests from a Market Surveillance Authority. There is no obligation to disclose the SBOM to third parties, but it must be provided to the Market Surveillance Authority on request. A1

SPDX and CycloneDX have established themselves as the de facto standard formats. SPDX was standardized as ISO/IEC 5962:2021 (based on SPDX v2.2.1; the current specification is v3.0), C3, C4 and CycloneDX, a specification maintained by OWASP, saw ECMA-424 2nd Edition (based on v1.7) published on December 10, 2025. C5 No official CRA-level implementing act for an SBOM schema has been issued as of June 2026. Technical Guideline TR-03183-2 v2.1.0, published in August 2025 by Germany’s Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI), serves as a practical reference point for field mapping to a CRA-conformant SBOM. G1

4. Reporting Obligations (Art. 14) — Effective 2026-09-11

4.1 Notification Triggers

Article 14 defines two categories of events that trigger a manufacturer’s notification obligation. A1, B2

One is an actively exploited vulnerability. The trigger is not the vulnerability’s mere theoretical existence but the confirmed point at which an attacker is actually exploiting it. The other is a severe incident — an event that has caused, or is likely to cause, serious operational disruption, loss, or damage affecting the security of the product.

Beyond manufacturers, importers and distributors must also notify the manufacturer of relevant information when they discover non-compliance or become aware of an incident.

4.2 The Three-Stage Deadline (24h/72h/14d)

Figure 3. CRA Article 14 reporting deadlines (Source: CRA Art. 14, EC “CRA — Reporting obligations”)

The required content differs at each stage. A1, B2

The CRA text makes clear that the 24-hour deadline does not require vulnerability classification or full resolution. Its purpose is simply to flag the existence of the issue as an early warning. Microenterprises and small enterprises may be exempted from fines for failing to meet the 24-hour deadline. A1

4.3 Single Reporting Platform (Art. 16)

All Article 14 notifications go through the Single Reporting Platform (SRP). Operated by ENISA, the SRP automatically routes a single manufacturer submission to both the coordinator Computer Security Incident Response Team (CSIRT) of the member state where the manufacturer’s main establishment is located and to ENISA itself. B4, A1

In procuring the SRP, ENISA required a forward-looking architecture capable of integrating with the incident and vulnerability reporting systems of NIS2 and DORA. The design goal extends beyond CRA obligations alone, aiming for a platform that can interoperate with adjacent regulatory regimes.

Figure 4. Stakeholder interactions in the CRA reporting system (Source: CRA Art. 13–16, Delegated Regulation (EU) 2026/881)

4.4 Conditions for Delaying CSIRT-to-CSIRT Dissemination (Delegated Regulation 2026/881)

Delegated Regulation (EU) 2026/881, adopted on December 11, 2025 (published in the Official Journal on April 20, 2026), sets out the conditions under which a member state CSIRT need not immediately disseminate a notification it has received via the Single Reporting Platform to other CSIRTs. A2 Delay is permitted where an assessment of the nature of the notified information justifies it, where the receiving CSIRT cannot guarantee the confidentiality of the information, or where the Single Reporting Platform itself has been compromised or is temporarily unable to operate. Beyond that, delay is allowed only for the “period strictly necessary,” and only when the risk cannot be mitigated through tools such as the Traffic Light Protocol (TLP) or the Permissible Actions Protocol (PAP).

The 24-hour deadline for a manufacturer’s notification to a CSIRT is unaffected by this Delegated Regulation. What the Delegated Regulation touches is the further dissemination step between CSIRTs, where it introduces a security-based relief mechanism.

4.5 Parallel Application with GDPR and NIS2

A CRA reporting obligation can arise alongside reporting obligations under other regulations. Where the data compromised by a vulnerability or incident includes personal data, a CRA notification does not substitute for the 72-hour notification obligation to the supervisory authority under Article 33 of the General Data Protection Regulation (GDPR). A5 The two notifications must go through separate channels to separate recipients — the data protection authority on one side, the CSIRT/ENISA on the other.

The same holds for operators of essential and important services covered by the NIS2 Directive (Directive (EU) 2022/2555) that become aware of a vulnerability or incident in their own products. Both a CRA report and a NIS2 report may be required simultaneously. The Digital Omnibus package’s “report once, share many” model is being discussed as a way to unify the two reporting obligations, but it has not yet been settled in legislation. A4, E2

5. Conformity Assessment and CE Marking (2027-12-11)

December 11, 2027 is the deadline for conformity assessment. The pathway differs by risk class. Default-class products may self-assess to issue an EU Declaration of Conformity and affix the CE marking. Important Class I products may either self-assess by applying EU harmonized standards or obtain an assessment from a third-party Conformity Assessment Body (CAB). Important Class II and critical-class products require enhanced examination by a CAB. A1, B3

In February 2025, ENISA published Cyber Resilience Act implementation via EUCC and its applicable technical elements, analyzing pathways for using EU Common Criteria (EUCC) certification in CRA conformity assessment. B6

From June 11, 2026, the provisions on notification of conformity assessment bodies apply. Each member state must designate a notifying authority by this date, and the accreditation process begins so that a sufficient number of notified bodies to carry out third-party conformity assessment are in place by December 11, 2026. B3

Penalties for non-compliance vary by the type of violation. The most serious violations — failure to meet essential requirements, breach of reporting obligations — can draw a fine of up to €15 million or 2.5% of worldwide annual turnover, whichever is greater, and can also result in an order to withdraw the product from the EU market. A1, E1

6. Standards and Framework Mapping

The CRA sets out only essential requirements and delegates technical detail to harmonized standards. CEN/CENELEC JTC 13 WG 9 is developing European harmonized standards (EN) for the CRA, targeting publication of the horizontal standards by August 30, 2026 and the vertical standards by October 30, 2026. The horizontal standards proceed as the prEN 40000-1 series, consisting of vocabulary (prEN 40000-1-1), principles (prEN 40000-1-2), vulnerability handling (prEN 40000-1-3), and general security requirements (prEN 40000-1-4). The final list of cited standards has not yet been settled, so the table below can be used as a set of candidate mappings for the time being. B5

C1, C2, C3, C4, C5, C6, G1, C7

The European Vulnerability Database (EUVD), implementing Article 12 of the NIS2 Directive, was formally launched by ENISA on May 13, 2025. F1 It can serve as a primary monitoring source for the CRA’s “vulnerability monitoring” requirement. The EUVD uses its own identifier (EUVD-YYYY-NNNNNN) while also recording the corresponding CVE ID and CVSS score. It is a separate system from the SRP: the SRP is the channel through which manufacturers notify authorities, while the EUVD is a public database. B4, F2

7. Recent Developments (2025–2026)

Since entry into force in December 2024, the regulatory landscape has taken shape along three tracks: delegated regulations, implementing regulations, and guidance.

Implementing Regulation (EU) 2025/2392 was adopted on November 28, 2025 and entered into force on December 21. It finalized the technical definitions dividing “important” and “critical” products — as referenced in CRA Annexes III and IV — into 28 categories, placed across the three tiers of Class I, Class II, and critical. This Regulation is the primary legal basis manufacturers use to determine the conformity assessment pathway for their products. A3

Delegated Regulation (EU) 2026/881 was adopted on December 11, 2025 and published in the Official Journal on April 20, 2026. It codifies the conditions under which CSIRT-to-CSIRT dissemination of notifications may be delayed (see §4.4). A2

Guidance documents have arrived in two stages. The Commission’s first official FAQ was published on December 3, 2025 (updated December 19), offering the first — non-binding — clarification of the scope and iterativeness of risk assessment and of the “intended purpose” concept. The first draft guidance under CRA Article 26 followed on March 3, 2026. Running to 75 pages, with roughly a quarter devoted to defining the open-source steward, the draft covered remote data processing solutions, free and open-source software, the support period, and the CRA’s interrelationship with other regulations such as NIS2 and DORA. The consultation closed on March 31, but the final version has not been issued as of June 2026. E3

The open source community’s collective response became visible on April 2, 2024, when seven foundations — the Apache Software Foundation, the Blender Foundation, the Eclipse Foundation, OpenSSL, the PHP Foundation, the Python Software Foundation, and the Rust Foundation — announced they would jointly develop common standards for secure software development. The effort was led by the Eclipse Foundation AISBL in Brussels and evolved, on September 24 of the same year, into the Open Regulatory Compliance Working Group (ORC WG), which published a white paper laying out the scope of a steward’s obligations. OpenSSF published its direction for aligning SBOM standards on October 22, 2025. F3, D1

The most persistent point of contention is the practical value of 24-hour notification. Security researchers, HackerOne among them, have repeatedly argued since 2024 that notifying authorities of a vulnerability’s existence before a patch is ready risks exposing an unmitigated vulnerability. E4 Delegated Regulation (EU) 2026/881 only introduced conditions for delaying CSIRT-to-CSIRT dissemination; it left the manufacturer’s 24-hour deadline to the CSIRT itself untouched.

8. A Korean Company Perspective — What to Do in the Next Three Months

8.1 Determining Whether the CRA Applies

The first step is to determine whether the reporting obligation, due September 11, 2026, applies to the company at all. Check in turn: whether the product is distributed in the EU market, whether the product is a product with digital elements, and whether stricter sector-specific cybersecurity legislation already applies. EU distribution covers direct sales, resale, and OEM supply alike, and the CRA applies even without an EU legal entity if the Korean headquarters exports directly. Software or hardware capable of data connection with a network or a device qualifies as a product with digital elements. Areas already covered by stricter regulation, such as medical devices or automotive safety, may be excluded from CRA application.

Legacy products are covered too. Many companies overlook the fact that the reporting obligation, effective September 11, applies even to products already placed on the EU market. E1

8.2 Preparation Steps

There is no need to have certification in place by September 11. What is needed is a reporting workflow. The company needs a human structure and technical connection able to send an early warning within 24 hours of becoming aware of a vulnerability or incident, and an on-call rotation, decision-making authority, and an external communications owner should all be designated in advance.

A pipeline that automatically generates and retains an SBOM in SPDX or CycloneDX format for every released version is also needed by September 11. The field mapping in BSI TR-03183-2 v2.1.0 can serve as a practical reference. G1

ENISA has stated that it does not provide an API for SRP integration at this stage (as of June 2026). Since the operations manual is expected during June, companies should build a manual submission process rather than assuming automated integration, and watch for ENISA’s manual and its announcements about the testing period.

A process for monitoring the EUVD (https://euvd.enisa.europa.eu) against the company’s own product components is also needed. The company must be able to handle both the CVE ID and EUVD-YYYY-NNNNNN identifier schemes.

By December 11, 2027, companies need to go a step further: CE marking, conformity assessment, selecting a CAB matched to the product’s class (for Class I and above), and issuing a declaration of conformity once the harmonized standards are published. Companies should track the publication of CEN/CENELEC’s horizontal standards (targeting August 30, 2026) and vertical standards (targeting October 30, 2026).

8.3 Comparison with Other Jurisdictions

C6, E2

The CRA’s most notable feature is its horizontal application, cutting across IoT, software, and embedded systems alike, combined with direct effect. Korea’s Software Supply Chain Guideline 1.0, based on NIST SSDF, recommends 30 checklist items and SBOM procedures; because the CRA’s essential requirements are functionally aligned with the SSDF, a system built to follow the Korean guideline is a starting point for CRA readiness. That said, the Korean guideline is advisory, whereas the CRA is a legal obligation backed by a fine regime, and the CRA adds a separate reporting obligation on top.

9. Conclusion and Recommendations

September 11, 2026 is the day the CRA first imposes a substantive compliance obligation on manufacturers. CE marking and conformity assessment are due by December 11, 2027, but the reporting workflow must be complete before then.

For a Korean company, the priority is first to confirm whether its products fall within CRA scope, and if so, to determine — under the criteria of Implementing Regulation (EU) 2025/2392 — which class applies: default, important, or critical. The class determines both the 2027 conformity assessment pathway and the lead time required to prepare for it.

Building the reporting infrastructure and internal playbook comes next. The SRP operations manual has not yet been released, but the human structure and internal procedures can be designed right now regardless. Since ENISA has said it will not provide an integration API, companies should set up a manual submission process for the platform rather than automated integration, and watch for the manual and announcements about the testing period.

SBOM pipeline automation must be finished by September 11. Without an SBOM in SPDX or CycloneDX format automatically generated and retained for every released version, a company will find itself lacking the very software composition information the reporting obligation requires. A1, B2, E2, E4

References

A. Primary Legislative and Regulatory Texts

A1. European Parliament and Council (2024). Regulation (EU) 2024/2847 of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed: 2026-05-12). ↩

A2. European Commission (2025). Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 supplementing Regulation (EU) 2024/2847 with regard to the conditions for delaying dissemination of notifications of actively exploited vulnerabilities and severe incidents. Published 20 April 2026. https://eur-lex.europa.eu/eli/reg_del/2026/881/oj (accessed: 2026-05-12). ↩

A3. European Commission (2025). Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 laying down technical descriptions of categories of important and critical products with digital elements. OJ L, 2025/2392. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202502392 (accessed: 2026-05-12). ↩

A4. European Parliament and Council (2022). Directive (EU) 2022/2555 of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2 Directive). OJ L 333, 27.12.2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng (accessed: 2026-05-12). ↩

A5. European Parliament and Council (2016). Regulation (EU) 2016/679 — General Data Protection Regulation (GDPR). OJ L 119, 4.5.2016. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 (accessed: 2026-05-12). ↩

B. Official Documents from Issuing Bodies

B1. European Commission, DG CNECT (2026). Cyber Resilience Act — Shaping Europe’s digital future. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (accessed: 2026-05-12). ↩

B2. European Commission, DG CNECT (2026). Cyber Resilience Act — Reporting obligations. https://digital-strategy.ec.europa.eu/en/policies/cra-reporting (accessed: 2026-05-12). ↩

B3. European Commission, DG CNECT (2024). The Cyber Resilience Act — Summary of the legislative text. https://digital-strategy.ec.europa.eu/en/policies/cra-summary (accessed: 2026-05-12). ↩

B4. ENISA (2026). Single Reporting Platform (SRP). https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp (accessed: 2026-05-12). ↩

B5. ENISA & Joint Research Centre (2024). Cyber Resilience Act Requirements Standards Mapping — Joint Analysis. April 2024. https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping (accessed: 2026-05-12). ↩

B6. ENISA (2025). Cyber Resilience Act implementation via EUCC and its applicable technical elements. 26 February 2025. https://certification.enisa.europa.eu/publications/cyber-resilience-act-implementation-eucc-and-its-applicable-technical-elements_en (accessed: 2026-05-12). ↩

C. Standards and Frameworks

C1. ISO/IEC (2019). ISO/IEC 30111:2019 — Information technology — Security techniques — Vulnerability handling processes. Edition 2. https://www.iso.org/standard/69725.html (accessed: 2026-05-12). ↩

C2. ISO/IEC (2018). ISO/IEC 29147:2018 — Information technology — Security techniques — Vulnerability disclosure. Edition 2. https://www.iso.org/standard/72311.html (accessed: 2026-05-12). ↩

C3. ISO/IEC (2021). ISO/IEC 5962:2021 — Information technology — SPDX® Specification V2.2.1. https://www.iso.org/standard/81870.html (accessed: 2026-05-12). ↩

C4. The Linux Foundation / SPDX Project (2024). SPDX Specifications (current: v3.0). https://spdx.dev/specifications/ (accessed: 2026-05-12). ↩

C5. OWASP Foundation / Ecma International (2025). CycloneDX Specification v1.7 / ECMA-424, 2nd Edition. ECMA-424 published 2025-12-10. https://cyclonedx.org/specification/overview/ (accessed: 2026-05-12). ↩

C6. Souppaya, M., Scarfone, K., Dodson, D. — NIST (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST SP 800-218. DOI: 10.6028/NIST.SP.800-218. https://csrc.nist.gov/publications/detail/sp/800-218/final (accessed: 2026-05-12). ↩

C7. OpenSSF Global Cyber Policy Working Group (2026). CRA Standards Map. https://policy.openssf.org/CRA/standards.html (accessed: 2026-06-09). — Used to verify the numbering and status of CEN/CENELEC JTC 13 WG 9’s prEN 40000-1 series (horizontal harmonized standards). ↩

D. Academic and Policy Research

D1. OpenSSF Best Practices WG / Global Cyber Policy WG (2025). Cyber Resilience Act (CRA) Brief Guide for Open Source Software (OSS) Developers. Lead author: David A. Wheeler. https://best.openssf.org/CRA-Brief-Guide-for-OSS-Developers.html (accessed: 2026-05-12). ↩

E. Industry and Law Firm Analysis

E1. Bird & Bird LLP (2026). CRA’s phased entry into application starts in September 2026. Bird & Bird Insights. https://www.twobirds.com/en/insights/2026/cra%E2%80%99s-phased-entry-into-application-starts-in-september-2026 (accessed: 2026-05-12). ↩

E2. DLA Piper — Blum, L. & Moylan Burke, L. (2026). Cyber Resilience Act: What you need to know and what you need to be doing. 19 February 2026. https://www.dlapiper.com/en/insights/publications/2026/02/cyber-resilience-act-what-you-need-to-know-and-what-you-need-to-be-doing (accessed: 2026-05-12). ↩

E3. DLA Piper (2026). Cyber Resilience Act: Commission unveils draft implementation guidance. Law in Tech. https://www.dlapiper.com/en-us/insights/publications/law-in-tech/2026/cyber-resilience-act (accessed: 2026-05-12). ↩

E4. HackerOne — Eldering, B. (2026). EU Cyber Resilience Act: Preparing Your VDP for 2026 Reporting Requirements. https://www.hackerone.com/blog/cyber-resilience-act-vdp-2026-reporting-readiness (accessed: 2026-05-12). ↩

F. Press and Official Announcements (Supplementary)

F1. ENISA (2025). Consult the European Vulnerability Database to enhance your digital security! News release, 13 May 2025. https://www.enisa.europa.eu/news/consult-the-european-vulnerability-database-to-enhance-your-digital-security (accessed: 2026-05-12). ↩

F2. European Commission (2025). EU launches a European vulnerability database to boost its digital security. https://digital-strategy.ec.europa.eu/en/news/eu-launches-european-vulnerability-database-boost-its-digital-security (accessed: 2026-05-12). ↩

F3. Eclipse Foundation (2024). The Open Source Community is Building Cybersecurity Processes for CRA Compliance. Life at Eclipse, 2 April 2024. https://eclipse-foundation.blog/2024/04/02/open-source-community-cra-compliance/ (accessed: 2026-05-29). ↩

G. Member State Technical Guidance

G1. Bundesamt für Sicherheit in der Informationstechnik (BSI) (2025). Technical Guideline TR-03183-2 v2.1.0 — Cyber Resilience Requirements for Manufacturers and Products, Part 2: Software Bill of Materials (SBOM). August 2025. Summary compiled by: Sbomify, EU Cyber Resilience Act (CRA) SBOM Requirements. https://sbomify.com/compliance/eu-cra/ (accessed: 2026-05-12). ↩