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

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

1. Document Overview

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

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

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

2. Background: Extending the OpenChain Methodology to AI

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

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

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

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

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

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

3. Structure and Requirements of the Guide

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

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

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

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

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

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

4. Regulatory and Governance Trends

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

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

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

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

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

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

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

5. Significance and Limitations

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

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

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

6. Process Requirements and Data Item Requirements

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

References

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

A. Primary Source and OpenChain/Standards

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

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

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

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

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

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

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

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

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

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

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

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

B. AI BOM Formats

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

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

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

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

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

C. Regulation and Governance

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

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

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

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

D. SBOM Policy Background

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

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

E. Supplementary (Academic/Industry)

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

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

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

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

One point to clarify first

It is hard to answer this question directly with a “yes” or “no.” As I will explain point by point below, what determines the answer is not AI itself. AI coding increases the rate at which code fragments not declared as packages flow in, but it does not change the conditions under which license obligations arise. So rather than asking “does scanning still matter in the age of AI,” it helps more to ask “under what conditions does snippet-level scanning become more important, and under what conditions does it become less important.”

Snippet scanning and SCA are different things

First, the terms need to be separated so the discussion doesn’t get tangled.

Software Composition Analysis (SCA) refers broadly to the activity of identifying open source that has entered the code and managing its vulnerabilities and licenses. Most SCA looks at declared dependencies, as in the first row of the table above. Snippet-level matching is a separate feature found in only some commercial tools; it compares the source code body against a large number of open source projects to find the origin of fragments that are not declared as packages. What this post addresses is not SCA as a whole but this snippet matching.

How much legal risk actually exists

Let’s start with cases where AI code snippets led to license violation disputes.

The most widely known case is the Copilot class action lawsuit that open source developers filed against GitHub, Microsoft, and OpenAI in November 2022. In May 2023, the copyright infringement claim was dismissed for lack of concrete evidence of copying, and in July 2024, the claim under Section 1202(b) of the Digital Millennium Copyright Act (DMCA) was also dismissed. This section prohibits removing copyright management information attached to an original work, and the court did not accept the claim on the grounds that the Copilot output was not sufficiently identical to the originalA2. Of the 22 claims originally filed, two remain: open source license violation and breach of contractA2·A3.

This carries facts that can be read in two directions.

On one hand, the defendants in disputes so far have all been vendors that built the AI tools, and no publicly reported case exists of an adopting company being sued solely for using AI-generated codeC1. Also, in September 2023, Microsoft announced through its Copilot Copyright Commitment that it would cover defense costs and damages if a paying commercial customer is sued by a third party over intellectual property arising from Copilot output. This comes with the condition that the customer must not disable the product’s built-in filtering features and must not intentionally generate infringing contentB1·C5.

On the other hand, the legal question has not been settled. The DMCA issue above has gone up to the Ninth Circuit Court of Appeals as an interlocutory appeal — where a specific issue is contested in a higher court before the trial court’s judgment — and as of June 2026, no ruling has come down, and the trial court proceedings remain pausedA1. The absence of reported precedent does not mean there is no risk.

When do license obligations arise

One distinction needs to be made here. Whether you get sued and whether you have an obligation to comply with a license are different questions. Even if no one files a lawsuit, the obligation to comply with an open source license remains. And when that obligation is triggered matters.

The copyleft obligation of GPL-family licenses, which requires disclosing source code, arises when software is distributed. Merely running software internally is use, not distribution, so no obligation arisesC3·C4. Pure SaaS that does not deliver code is likewise outside GPL obligations for the same reason. Two caveats apply here.

• AGPL is a stricter license that treats even providing a network service as distribution. If you use a component licensed under AGPL, the source disclosure obligation arises even if you provide it only as a service without directly delivering the codeC3. Such components can be managed by excluding them through internal policy.
• “Internal” must mean use limited to the company’s own employees, and if distribution occurs later — through an acquisition or open-sourcing — the issue arises at that point.

Whether short code is even copyrightable is also worth examining. A few lines of functional code may be too trivial an amount of copying to pursue (de minimis), or may fall outside protection because there is effectively only one way to express it (merger doctrine)A4·A5. That said, this is a case-by-case determination, and longer, creative code blocks are protected, so it is hard to say all snippets are free to use.

In practice, it is common for small fragments to come with obligations attached. Code from Stack Overflow, which developers frequently copy, is licensed under CC BY-SA, carrying attribution and share-alike obligations. According to one study, the proportion of GitHub projects that used this code in compliance with the license was at most 1.8%C6. This means even small fragments can carry license obligations, and that obligation is widely not observed.

Do standards require snippet scanning

OpenChain ISO/IEC 5230, the international standard for open source license compliance, focuses on defining where the compliance process sits, how roles and responsibilities are allocated, and how the process is sustainedA6. It is a non-prescriptive standard that sets what must be achieved while leaving the specific method to the organization, so it does not mandate a particular technique such as snippet scanningA6·A7. What the standard requires is identifying third-party components and maintaining a list of them — a Software Bill of Materials (SBOM). What matters for meeting the standard is grasping which components entered the code; it does not require analyzing the origin of every single code fragment. In fact, many widely used SCA tools on the market operate at the dependency level only, without snippet matching.

This fact can be read two ways. It means the standard can be met without snippet scanning, since the standard does not require it, and at the same time it means an area remains that the standard does not cover. Dependency-level scanning cannot see fragments that were copied or AI-generated without being declared as a package. Snippet matching is the feature that fills exactly that gap, and some organizations perform it for more thorough intellectual property management.

Under what conditions does it become more important

How much weight snippet scanning deserves depends on two conditions a company faces.

First, whether the company delivers code or binaries directly to customers. When code leaves the company — as with on-premises installed products, mobile apps, SDKs, or embedded device firmware — this counts as distribution and can trigger copyleft obligations. Pure SaaS that does not deliver code carries a smaller burden.

Second, whether the company undergoes external verification — situations where someone outside the company actually checks the origin of the code, such as M&A due diligence, a large customer’s security audit, regulatory requirements, or an SBOM submission that demands snippet-level detail.

The more these two overlap, the greater the chance that a latent obligation surfaces as an actual cost. Even if code is delivered, if there is no verification trigger, the risk stays latent, and if code is not delivered, the obligation itself rarely arises. Neither condition has anything to do with whether AI is used. AI coding is a factor that increases the inflow volume once a condition holds, not a factor that creates the condition.

Looking at it by company condition

Placing the two conditions above on two axes yields four quadrants.

Figure 1. How much weight snippet scanning deserves, by condition

The top-right quadrant carries the greatest burden: code leaves the company, creating a license obligation, and there is also a trigger — such as M&A due diligence or a customer audit — that actually looks into that obligation. In the top-left, even if an obligation arises, there is no one to check it, so it stays latent. In the bottom two quadrants, there is no distribution at all, so an obligation rarely arises to begin with.

This diagram is a starting point for judgment, not a definitive answer. Even within the same quadrant, the choice can vary depending on the nature of the code involved, the types of licenses used, and the company’s risk tolerance.

Embedded software is a different case

Everything so far has assumed software built through a package manager. Software that runs as embedded or firmware code — routers, set-top boxes, IoT devices, automotive controllers — is a different case. It is mostly written in C/C++, and open source is often copied in as raw source directly into the project without a manifest. In this case, dependency-level SCA has no manifest to read and can barely see the open source at all.

One distinction is needed. For large components brought in wholesale, such as the Linux kernel or BusyBox, the company is usually aware it is using them. That is not a discovery problem but a matter of whether the source disclosure obligation is being met. Where snippet scanning is needed is different: small code fragments pulled in bits and pieces from various open source projects that no one has listed anywhere. Finding these fragments, which dependency-level SCA cannot see, is the job of snippet scanning.

So in embedded software, snippet scanning is not a conditional supplement but closer to a basic means of finding undeclared open source fragments.

Filtering code before it comes in

Apart from scanning after the fact, there is also a way to block problem code before it comes in. GitHub Copilot has a setting that blocks suggestions matching public code verbatim. Suggestions that match public code exactly at a certain length (on average, roughly 150 characters) or longer are simply not shownB2·C2. GitHub has stated that verbatim duplication over 150 characters occurs at about the 1% level, though independent studies report higher figures depending on context. Either way it is not zero, but turning on this setting reduces the inflow of fragments with unclear provenance. It costs almost nothing, and it is also a precondition for the vendor indemnification discussed earlier.

This setting overlaps in purpose with after-the-fact snippet scanning. One finds fragments after they come in; the other blocks them before they come in. Which of the two to use, and to what extent, is a matter to decide by weighing the conditions above together with cost.

Putting the inflow paths and inspection methods covered so far in one place looks like this.

Figure 2. Code inflow paths and the methods that catch them

Where the blind spot of dependency-level SCA lies, and how snippet matching fills that spot, is the starting point for this judgment.

Criteria for the decision

There is a reason this decision is not simple. Snippet matching is effectively the only way to find code fragments that entered without being declared as a package, whether copied or AI-generated. Neither dependency-level SCA nor code-filtering settings catch all of those fragments. So a small residual area remains that only snippet matching fills. Yet at many companies, that small area rarely translates into actual loss, and snippet scanning costs tool spend and review effort. In the end, this comes down to deciding whether to spend that much to guard against this small risk.

There are four points to examine when making this decision.

• Does the company send code outside the organization? — The more it does, the greater the room for a copyleft obligation to actually arise.
• Does the company undergo external verification? — M&A due diligence or a customer audit can surface an obligation that had been buried until then.
• How much license risk is the company willing to accept? — There is no reported litigation precedent, but the legal question is not settled either. How to weigh this uncertainty is up to the company to decide.
• Are other inspection measures already in place? — If dependency-level SCA, an AI tool setting that blocks suggestions matching public code verbatim, and a policy excluding AGPL components are already running, the additional share that snippet scanning would catch shrinks accordingly.

One more point is worth adding. Snippet scanning does not have to be decided as an all-or-nothing choice, always on or never done. The occasions when an outside party actually looks into code provenance are largely predictable: M&A due diligence or a large customer’s audit. So one option is to run only dependency scanning and the blocking setting normally, and undergo a one-time snippet scan when such an occasion is anticipated.

Weighing the four points above and this operating approach against your own company’s situation, the answer to how much weight to give snippet scanning will differ from company to company. The exception is embedded software built without a manifest. There, snippet scanning is not a conditional supplement but a basic means of finding undeclared open source fragments.

Security vulnerabilities are a separate matter

Everything up to this point has been about licensing. Security vulnerabilities are a different axis, and the conditional conclusions above should not simply be applied here. If vulnerable open source is present in the code, it is dangerous whether or not it is distributed and whether or not it is audited, because even code that stays internal-only or sits in a pure SaaS backend is exposed to attack. So vulnerability inspection is broadly needed at nearly every company.

Tools handling security inspection fall broadly into two kinds.

• Dependency-level SCA — Looks at the name and version of declared open source libraries and checks them against known vulnerability (CVE) listsD1. Known vulnerabilities in libraries that AI pulled in are caught here.
• SAST (static analysis) — Finds risky coding patterns in the source code itself, regardless of where the code came from. This is where the primary security risk of AI code lies. One study found vulnerabilities in about 40% of 1,689 programs generated by CopilotD2.

Whether code was copied in or generated by AI, security vulnerability inspection is no different from any other code. SAST catches risky coding patterns in the code itself, and dependency-level SCA catches known vulnerabilities in libraries that were pulled in. Snippet scanning is a feature for finding license origin, so it is not a tool used for security inspection.

One exception worth noting: the rare case where code with a known vulnerability was copied in verbatim, yet it triggers no SAST pattern and appears in no dependency list. Catching this requires not the snippet feature that finds license origin, but an inspection that directly compares a vulnerable-code signature built from a CVE patch against your own code — vulnerable code clone detectionD3. Academic tools and some commercial tools provide this.

Sources

A1. BakerHostetler (2025).Doe v. GitHub, Inc. — The Copilot Litigation.https://www.bakerlaw.com/the-copilot-litigation/ (accessed: 2026-06-08). — Claim-by-claim progress of the Copilot class action and its status pending before the Ninth Circuit Court of Appeals.↩

A2. Claburn, T. (2024).Judge dismisses DMCA copyright claim in GitHub Copilot suit. The Register, 2024-07-08.https://www.theregister.com/2024/07/08/github_copilot_dmca/ (accessed: 2026-06-08). — Dismissal of the DMCA §1202(b) claim; 2 of the original 22 claims remain (license violation, breach of contract).↩

A3. Pearl Cohen (2024).Copyright Claims Against GitHub, Microsoft, and OpenAI Largely Dismissed.https://www.pearlcohen.com/copyright-claims-against-github-microsoft-and-openai-largely-dismissed/ (accessed: 2026-06-08). — Overview of the dismissal of most claims and the claims that remain.↩

A4. Goldstein Patent Law.Understanding the Copyright Merger Doctrine.https://www.goldsteinpatentlaw.com/copyright-merger-doctrine/ (accessed: 2026-06-08). — The merger doctrine, which denies copyrightability to functional code.↩

A5. NYU Journal of Intellectual Property & Entertainment Law.Clarifying the De Minimis Doctrine in Copyright Law.https://jipel.law.nyu.edu/clarifying-the-de-minimis-doctrine-in-copyright-law/ (accessed: 2026-06-08). — The de minimis doctrine, which does not treat trivial copying as infringement.↩

A6. OpenChain Project.OpenChain ISO/IEC 5230 — License Compliance.https://openchainproject.org/license-compliance (accessed: 2026-06-08). — That the standard defines process and roles but does not mandate a specific technique such as snippet scanning.↩

A7. ISO.ISO/IEC 5230:2020 — Information technology — OpenChain Specification.https://www.iso.org/standard/81039.html (accessed: 2026-06-08). — Bibliographic information for the standard text.↩

B1. Microsoft (2023-09-07).Microsoft announces new Copilot Copyright Commitment for customers.https://blogs.microsoft.com/on-the-issues/2023/09/07/copilot-copyright-commitment-ai-legal-concerns/ (accessed: 2026-06-08). — Intellectual property indemnification for paying commercial customers and the condition of keeping the built-in filtering feature enabled.↩

B2. GitHub.GitHub Copilot (product page).https://github.com/features/copilot (accessed: 2026-06-08). — The existence and operation of the setting that blocks matches with public code.↩

C1. TechTarget.AI lawsuits explained: Who’s getting sued?.https://www.techtarget.com/whatis/feature/AI-lawsuits-explained-Whos-getting-sued (accessed: 2026-06-08). — Evidence that lawsuit defendants have been concentrated among vendors, with no reported cases of adopting companies being sued.↩

C2. Microsoft Community Hub.Demystifying GitHub Copilot Security Controls.https://techcommunity.microsoft.com/blog/azuredevcommunityblog/demystifying-github-copilot-security-controls-easing-concerns-for-organizational/4468193 (accessed: 2026-06-08). — The roughly 150-character match threshold for the public-code-match blocking setting and the roughly 1% duplication rate.↩

C3. Mend.io.The SaaS Loophole In GPL Open Source Licenses.https://www.mend.io/blog/the-saas-loophole-in-gpl-open-source-licenses/ (accessed: 2026-06-08). — The distribution trigger for copyleft, why internal use and SaaS do not qualify, and the AGPL Section 13 exception.↩

C4. Revenera.Understanding the SaaS Loophole in GPL.https://www.revenera.com/blog/software-composition-analysis/understanding-the-saas-loophole-in-gpl/ (accessed: 2026-06-08). — Additional support on the distribution trigger and the SaaS exception.↩

C5. TechTarget.Microsoft Copilot Copyright Commitment explained.https://www.techtarget.com/searchenterprisedesktop/tip/Microsoft-Copilot-Copyright-Commitment-explained (accessed: 2026-06-08). — Additional support on the scope and conditions of the indemnification.↩

C6. Baltes, S. & Diehl, S. (2019).Usage and Attribution of Stack Overflow Code Snippets in GitHub Projects. Empirical Software Engineering, arXiv:1802.02938.https://arxiv.org/abs/1802.02938 (accessed: 2026-06-08). — An empirical study finding that the rate of license-compliant use of Stack Overflow code (CC BY-SA) in GitHub projects was at most 1.8%.↩

D1. Cycode.What Is Software Composition Analysis (SCA)?.https://cycode.com/blog/what-is-software-composition-analysis-sca/ (accessed: 2026-06-08). — How SCA finds vulnerabilities by checking components and versions against CVE/NVD.↩

D2. Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2022).Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. IEEE S&P 2022, arXiv:2108.09293.https://arxiv.org/abs/2108.09293 (accessed: 2026-06-08). — Vulnerabilities in about 40% of 1,689 programs generated across 89 scenarios.↩

D3. Kim, S., Woo, S., Lee, H., & Oh, H. (2017).VUDDY: A Scalable Approach for Vulnerable Code Clone Discovery. IEEE S&P 2017.https://seulbae-security.github.io/pubs/vuddy-sp17.pdf (accessed: 2026-06-08). — The problem of vulnerabilities propagating through copied code and copies remaining unpatched even after an upstream patch, and detection of this.↩

Research as of: 2026-06-08

This guide explains, one by one, each requirement ofAI System Bill of Materials — Compliance Management Guide for the Supply Chain (Version 1.0), published by the OpenChain AI Work Group. It walks through what verification material each clause requires, how to comply with it, and what samples and tools are ready to use.

This specification carries the same structure as ISO/IEC 5230, the open source license compliance standard — requirements, verification material, and rationale — over into the AI supply chain. It brings into scope not only code but also the licensing and transparency obligations of model weights, training datasets, and the Model Tree.

Author : OpenChain Korea Work Group /CC BY 4.0

Intended Audience

• Compliance staff at organizations that develop AI systems or exchange them through the supply chain
• Practitioners who have an open source compliance (ISO/IEC 5230) program in place and want to extend it into AI
• Legal, security, and development staff who need to check the licensing and transparency obligations of AI models and datasets

How to Use This Guide

Phased Implementation Roadmap

The 10 requirements are divided into four phases by implementation priority. Phase 1 establishes the program’s foundation, Phase 2 builds AI-specific compliance processes, Phase 3 puts operational structures in place, and Phase 4 establishes governance.

Phase 1 — Program Foundation

Goal: Define the program’s scope, establish policy, and secure competence and awareness.

Phase 2 — AI Extension Processes

Goal: Build AI-specific licensing, transparency, and SBOM processes that cover not just code but also models, weights, and datasets. This is the area where the AI SBOM Guide expands most on ISO/IEC 5230.

Phase 3 — Operational Structure

Goal: Create a channel for responding to external compliance inquiries, and assign accountability and resources to the program.

Phase 4 — Governance

Goal: Put in place a governance framework spanning the full AI system lifecycle, and reflect emerging AI regulation.

Full Clause Checklist

The body of the AI SBOM Compliance Guide consists of10 clauses and 19 verification material items in total (by this guide’s verification material numbering).

Total: 10 clauses / 19 verification material items

Automation Maturity Map

This is an honest breakdown of how far each AI SBOM compliance task is automated by tools today. For “generation,” usable open source tools already exist. Interpreting license obligations and tracking compliance with non-standard licenses, on the other hand, remain the work of people and policy. Each clause page follows this line to distinguish “what a tool handles” from “what a person must fill in.”

The installation and use of each tool is covered with execution screens and command output in theTools section.

Relationship to Other Standards

Original Specification

1. What Is the OpenChain Project?

Today, software continues to grow in scale and complexity. Developing a single piece of software can involve not only software built in-house but also a variety of software spanning the software supply chain, including open source, third-party software, and vendor SDKs.

If even a single organization within this complex software supply chain fails to comply with open source license obligations or fails to provide accurate information about its open source use, the enterprise distributing the final software has no choice but to fail at meeting its own open source license obligations. This can result in lawsuits and even the suspension of product sales.

In December 2009, a lawsuit arose involving the open source projectBusybox. Busybox is open source licensed under GPL-2.0 that is widely used in embedded systems, and 14 companies, including two South Korean companies, became subject to the lawsuit. A notable point in this case is that among the defendants were companies that were sued despite not developing the product themselves but only distributing it.

In such a complex software supply chain environment, it is very difficult for any single enterprise, no matter how excellent its processes are, to achieve perfect open source compliance on its own. Ultimately, for an enterprise to properly implement open source compliance, every member of the software supply chain must comply with license obligations and provide accurate open source information. This kind of trust must be built across the entire supply chain.

TheOpenChain project, part of theLinux Foundation, was founded on the belief that concisely and consistently defining the core requirements enterprises must meet for open source compliance, and having everyone comply with them, can build trust in open source licensing across the entire software supply chain.

At an open source conference in Europe in 2016, Dave Marr, an open source attorney at Qualcomm, emphasized exactly this point. To raise one enterprise’s level of open source compliance, the compliance level of every member across the software supply chain must be raised. He further suggested that, to achieve this, leading enterprises that already have a solid understanding of open source and have established policies and processes should openly share their assets and know-how so that anyone could reference them. Conference attendees agreed with the idea that “open source compliance is not an area where enterprises can differentiate their profits. Enterprises want an appropriate level of risk management while investing minimal resources. That is why the more enterprises share their assets with one another, the more everyone can achieve compliance together with fewer resources.” This is how the OpenChain project (then called a Work Group) began, with numerous global enterprises participating, includingQualcomm,Siemens,Wind River,ARM, andAdobe.

The OpenChain project provides three main things to help enterprises more easily achieve open source compliance.

1. OpenChain Specification
2. OpenChain Conformance Certification
3. Documentation Resources

Let’s look at how enterprises can make use of each of these, one by one.

2. The OpenChain Specification and ISO/IEC Standards

The OpenChain Specification is a 10-page document that defines the core requirements for open source compliance. Version 1.0 of the OpenChain Specification was published in 2016. The OpenChain Specification is designed to be suitable for any enterprise, regardless of size or industry.

In 2020, version 2.1 of the specification was released, defining the six core requirements that enterprises must fulfill to achieve open source compliance, along with the list of materials needed to demonstrate them.

1. Program Establishment
2. Defining and Supporting Related Tasks
3. Reviewing and Approving Open Source Content
4. Creating and Delivering Compliance Artifacts
5. Understanding Open Source Community Engagement
6. Conformance to Specification Requirements

For an enterprise just starting out with open source compliance, a good strategy is to raise its maturity level by fulfilling these OpenChain Specification requirements one by one.

In December 2020, this OpenChain Specification was formally registered asISO/IEC 5230:2020, the international standard for open source compliance.

The OpenChain Specification, which had served as a de facto standard for the previous four years, was converted into the formal international standard ISO/IEC 5230:2020 — the first international standard to define open source compliance and process management. As a result, interest among global IT enterprises in complying with ISO/IEC 5230 is rising, and more enterprises are expected to require ISO/IEC 5230 compliance from their suppliers across the software supply chain.

In 2023,ISO/IEC 18974, a new standard for open source security assurance, was published. This standard is based on the OpenChain Security Assurance Specification and defines the core requirements for managing known security vulnerabilities in open source software. ISO/IEC 18974 covers the following key areas:

1. Identifying the core areas requiring security processes
2. How to assign roles and responsibilities
3. How to ensure the sustainability of the process

Like ISO/IEC 5230, ISO/IEC 18974 is concise and easy to understand, and it is backed by the global community, providing free reference materials and conformance resources.

Together, these two standards support organizations in effectively managing both license compliance and security assurance for open source software. Where ISO/IEC 5230 focuses on license compliance, ISO/IEC 18974 focuses on vulnerability management, making the two mutually complementary.

3. How to Certify to the ISO/IEC Standards

If an enterprise complies with all the requirements of both ISO/IEC 5230 and ISO/IEC 18974, it can be certified as having an open source program conforming to these standards. An open source program refers to the set of management systems — including policies, processes, and personnel — that an enterprise uses to carry out its open source compliance and security assurance activities.

The image below lists the item numbers required by ISO/IEC 5230. An enterprise that fulfills all these items can be recognized as having built a transparent and trustworthy open source governance system within the software supply chain.

TheOpenChain project proposes three certification methods:

• Self-Certification
• Independent Assessment
• Third-Party Certification

Let’s look at each method.

(1) Self-Certification

Self-certification is the method most recommended by the OpenChain project and has the advantage of incurring no cost. The OpenChain Project provides anISO/IEC 5230 self-certification website so that enterprises can verify on their own whether they comply with the OpenChain Specification. An enterprise’s open source manager can sign up on this website and begin the online self-certification process. Self-certification proceeds by answering Yes/No questions, as shown below.

If an enterprise has built its open source compliance system well enough to answer Yes to every question in the OpenChain self-certification, it can submit the result on the website (Conforming Submission). After a brief question-and-answer verification process with theLinux Foundation, it can then declare ISO/IEC 5230 certification.

By making this certification declaration, an enterprise is recognized within the global software supply chain as having an open source program that conforms to ISO/IEC 5230.

The OpenChain project recommends the self-certification method. For reference, most enterprises that have declared OpenChain conformance have also adopted self-certification.

In addition, going through the self-certification process lets an enterprise determine what is lacking and what additional activities are needed. This guide explains, by major component — organization, policy, process, and so on — how to meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

For an enterprise that lacks the capability to make improvements on its own using only this guide, the independent assessment method can be considered.

(2) Independent Assessment

In an independent assessment, an independent organization outside the enterprise inspects and evaluates the enterprise’s open source compliance and security assurance status from an impartial standpoint. What distinguishes independent assessment is that it does not stop at producing an assessment report, but also provides consulting to address the gaps identified. (It does not, however, issue an official certificate.)

By receiving impartial assessment and consulting from an independent organization, an enterprise can raise its compliance and security assurance level, and through the iterative process of undergoing independent assessment again, refine its policies and build out its processes.

Eventually, the enterprise reaches a level where it can obtain ISO/IEC 5230 and ISO/IEC 18974 certification, at which point it can move into the process of obtaining self-certification or third-party certification. In this way, independent assessment provides evaluation and consulting to raise an enterprise’s open source compliance and security assurance level, supporting the enterprise in holding a conformant ISO/IEC 5230 and ISO/IEC 18974 program and obtaining certification.

Companies that provide independent assessment includeAlektoMetis andSource Code Control, among others.

In South Korea, theConformance Group, a subgroup of the OpenChain Korea Work Group, is a community where enterprises discuss and share methods for achieving ISO/IEC 5230 and ISO/IEC 18974 conformance on their own. Anyone who is a member of the OpenChain Korea Work Group can participate and get help.

(3) Third-Party Certification

An enterprise wishing to demonstrate a more reliable and transparent level of open source compliance and security assurance to buyers in the software supply chain can obtain a certificate from a third-party certification body and use it for promotional purposes. In addition, some buyers who demand stronger assurance of open source compliance and security may come to require third-party certification from their suppliers.

As of 2024, OpenChain’s authorized third-party certification bodies areORCRO,PWC,TÜV SÜD,Synopsys, andBureau Veritas.

These bodies provide assessments to verify conformant ISO/IEC 5230 and ISO/IEC 18974 programs and issue certificates to enterprises that pass.

As of 2024, buyers or organizations that mandatorily require third-party certification are not yet common. However, some experts in the European automotive industry predict that it will not be long before ISO/IEC 5230 and ISO/IEC 18974 become mandatory for automotive software suppliers, much likeASPICE (Automotive SPICE, an international standard process model for automotive software development).

In addition, detailed self-certification methods can be found in the following slides:

• OpenChain Korea 9th Meeting - How to Self Certify

4. OpenChain Resources

TheOpenChain project provides a variety of documentation resources that enterprises need to build a compliance program, including policy document templates and training materials. These materials are designed to support conformance with the OpenChain Specification and general open source compliance activities, and are provided under the CC-0 license so that anyone can use them freely.

Much of this guide was also written based on materials published by OpenChain. If an enterprise’s open source manager needs policies, processes, or training materials, they should look to the OpenChain Resources first. These materials are also translated into Korean and published. TheOpenChain Korea Work Group leads this translation effort. Anyone interested canparticipate in the Korean translation.

The OpenChain project also provides additional resources by running various webinars and study groups:

1. Webinars: The OpenChain project regularly hosts webinars to share the latest trends and best practices in open source compliance and security. These webinars can be found on theOpenChain website, where recordings are also available.

2. Training Materials: The OpenChain project provides acomprehensive training curriculum to help enterprises develop internal training programs. This material covers a range of topics, from the basic concepts of open source software to license compliance and security assurance.

By making use of these various resources, an enterprise can build and maintain a strong open source program that conforms to the ISO/IEC 5230 and ISO/IEC 18974 standards.

5. Trends in ISO/IEC Standard Adoption

Adoption of the ISO/IEC 5230 and ISO/IEC 18974 standards is showing a gradually expanding trend across the global software supply chain.

In early 2021, news emerged that a German automaker had begun requiring its parts suppliers to have an ISO/IEC 5230 compliance plan. In response, a European open source professor predicted that “it is clear that buyers in the software supply chain will increasingly require suppliers to comply with ISO/IEC 5230,” adding that “in the automotive industry, it will come to occupy the same position as ASPICE.”

Reflecting this outlook, in May 2021,Scania, part of the Volkswagen Group, incorporated a requirement for ISO/IEC 5230 compliance into its own corporate standard (STD 4589) that suppliers must follow.

Also, in July 2021,Bosch, an automotive and industrial technology company, declared that all of its group companies would have an ISO/IEC 5230-compliant program by the end of the year. The industry outlook is that it is only a matter of time before every automaker, and other industries as well, begin requiring ISO/IEC 5230 within their software supply chains.

In 2023, ISO/IEC 18974, a new standard for open source security assurance, was published. This standard defines the core requirements for managing known security vulnerabilities in open source software. Together with ISO/IEC 5230, ISO/IEC 18974 supports organizations in effectively managing both license compliance and security assurance for open source software.

As of 2024, this trend is accelerating further. For example,KT announced in October 2024 that it had obtained ISO/IEC 18974 certification. This shows that South Korean enterprises, too, are actively adopting international standards for open source security management.

The activities of theOpenChain Korea Work Group are also becoming more active. At its 22nd regular meeting held in June 2024, discussions covered the state of readiness for the ISO/IEC 18974 open source security standard and SBOM-based software supply chain management guidelines. This shows that South Korean enterprises are actively embracing the ISO/IEC 5230 and ISO/IEC 18974 standards.

This trend is expected to continue. As the complexity of the software supply chain increases and security threats grow, the importance of international standards such as ISO/IEC 5230 and ISO/IEC 18974 is likely to grow further. By complying with these standards, enterprises will be able to increase transparency in their open source use and effectively manage security risk.