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 project Busybox. 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.
The OpenChain project, part of the Linux 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, including Qualcomm, Siemens, Wind River, ARM, and Adobe.
The OpenChain project provides three main things to help enterprises more easily achieve open source compliance.
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.
- Program Establishment
- Defining and Supporting Related Tasks
- Reviewing and Approving Open Source Content
- Creating and Delivering Compliance Artifacts
- Understanding Open Source Community Engagement
- 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 as ISO/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:
- Identifying the core areas requiring security processes
- How to assign roles and responsibilities
- 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.
The OpenChain 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 an ISO/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 the Linux 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 include AlektoMetis and Source Code Control, among others.
In South Korea, the Conformance 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 are ORCRO, PWC, TÜV SÜD, Synopsys, and Bureau 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 like ASPICE (Automotive SPICE, an international standard process model for automotive software development).
In addition, detailed self-certification methods can be found in the following slides:
4. OpenChain Resources
The OpenChain 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. The OpenChain Korea Work Group leads this translation effort. Anyone interested can participate in the Korean translation.
The OpenChain project also provides additional resources by running various webinars and study groups:
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 the OpenChain website, where recordings are also available.
Training Materials: The OpenChain project provides a comprehensive 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 the OpenChain 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.