The OpenChain specification explained

TL;DR the OpenChain specification outlines the key requirements and processes that should be in place to be compliant. This includes having a process for reviewing and managing your open-source software and ensuring the required people are informed in your organisation.

What is the OpenChain specification?

OpenChain is currently on its fifth revision: OpenChain 2.1 which is functionally identical to ISO 5230.

ISO standards are developed by the International Organisation for Standardisation, which is an international NGO (non-governmental organisation) that generates and publishes standards that are agreed upon by industry experts. Common standards you might come across daily without realising are ISO 8601 – the internationally accepted way to represent dates and times, ISO 3166 – which defines country codes to avoid confusion when referring to countries, and ISO 4217 – which defines codes that refer to world currencies. By looking at these three key examples, we can see the importance of setting standards, for example, ISO 4217 which focuses on currency codes, standardises over 300 different currencies which could otherwise be confused with each other.

ISO and IEC (International Electrotechnical Commission) publish the ISO/IEC 5230. The IEC produce standards more specific to electrical, electronic, and related technologies. The standard defines the requirements for the open source licence compliance program. The standard can be bought directly from the ISO - ISO/IEC 5230:2020 - Information technology — OpenChain Specification or be found on the OpenChain website.

Conforming to OpenChain

Meeting the standards of the specification means that an organisation is fully compliant with OpenChain, and to get the certification to prove this, numerous items need to be provided. As stated on the OpenChain website, this includes source code, build scripts, licence copies, attribution notices, modification notices, SPDX (Software Package Data Exchange) data and other materials open-source licences governing a software deliverable may require. An organisation must meet all the requirements set out in the specification for them to be considered OpenChain conforming.

Compliance practices include:

• Identifying every open-source software component in use (including those indirectly used)
• Determine which licence each open-source component uses
• Review open-source practices and ensure licence obligations are met
• Fulfilment of licence obligations when a product is released
• Make sure there is an overview of the Open-Source Compliance Program
• Making sure participants are trained
• One way in which tracking open-source software is made easier is through an SBOM.

You can either self-certify with OpenChain or work with a service provider for independent assessment or third-party certification. To self-certify there is a free web app OpenChain provides which contains a list of questions to determine your position. To get involvement from a third party, OpenChain has provided a list of certified partners. The benefit of having an OpenChain certification is that it provides proof that your systems are set up to be secure and that dependencies are in control.

Delving deeper into the specification

The below diagram breaks down the specification into main chunks. These are a summarised version of the document, to find all the requirements, you can locate the official document here: Open Chain Specification

Main aspects of the specification:

Internal Communication

One of the first focuses in the specification is how employees interact with the process and the responsibilities associated with them. There are requirements for documentation to be in place so that employees are aware of the open-source policies. They can be made aware of this either through training, or internal communication. The roles assigned to participants should be documented along with their responsibilities, including the consequences of what could happen if the policy isn't followed correctly. It should highlight how their contribution will help the project be more effective, alongside the program’s objectives so that everyone is aware of the program.

Open-source policy

The program should contain a documented open-source policy which covers practices if an organisation is creating new open-source software, using other open-source software or contributing to open-source software that already exists. The open-source policy will cover all aspects of controlling open-source software, including licensing (which licences are acceptable), reviewing and requirements. For creating and contributing to open-source software this could include which licences to use, and any structures or processes that must be followed when formatting and publishing the code. When using open-source software, the policy could cover which licences the software has, the requirements stated by these licences, and how third-party software is managed. At this stage, there should be decisions around the scope of the open-source compliance program, and the limits associated with it also, for example, there is only funding to focus on one project or whether to implement it throughout the whole organisation.

SBOMs

A bill of materials is a list of raw materials and components needed to construct or repair a product or service. For example, for a house, you would list all the materials (including quantities) and machinery needed for the entire house.

A software bill of materials (SBOM) is a list of all software components that make up a piece of software. Having an SBOM means that you can track all the components required to run your code and therefore can automate the updates that, like in Equifax, should be patched. There are different standards for SBOMs to provide a uniform language so that it can be used more regularly and with a common structure to provide information to other systems. The most popular standards are CycloneDX and Software Package Data Exchange (SPDX). CycloneDX is designed for cybersecurity use cases where SPDX is for sharing SBOM material such as software components, licences, copyrights and other metadata across numerous file formats.

The SBOM can track all the licences for the given software, meaning it creates a great base for automating the tracking of the usage of an organisation's open-source software, this is called Software Composition Analysis. This is the process of tracking all the open-source software within an organisation. The SBOM can track each component and it's open-source licence. Processes can then be built around this, highlighting the requirements for each licence and whether the organisation will be able to uphold the requirements of that license. From here on, more processes can be made to approve this information, about whether licensing is up-to-date, or whether the open-source software complies with the licensing.

For example, there could be a deeply nested dependency that has a known vulnerability. Had an SBOM not highlighted its presence, it could have been impossible to know that it was there. Consequently, hackers could find the existence of the vulnerability and exploit it. In the instance of the log4j attack, many of the organisations hit by the vulnerabilities didn't know they were using log4j as their dependency trees were so large and they had no idea that log4j was a transitive dependency (an indirect relationship causing a functional dependency). Having SBOMs that combines all the components being depended on can easily become an easy solution to discovering all the dependencies in a system. Had everyone had SBOMs tracking their dependencies, it is more likely they could've spotted that log4j needed to be upgraded to fix the vulnerability.

Once all these processes have been put in place, there needs to be a method in place so that anyone externally can contact the organisation about open-source licensing enquiries. This could include a given email address or the Linux Foundation’s Open Compliance Directory.

How do you get started?

On the OpenChain website, there is an OpenChain Self Certification questionnaire that you can fill out. This will give you an indication of where you currently are with open-source compliance, and what you still need to implement.

There are resources available to help you along the way, such as:

• Training slides
• Playbooks - Shows how different size companies can use OpenChain
• Webinars - Wide range of relevant content from 'Getting started with OpenChain' to 'Agile Development' and real-world examples
• Templates - Contains the reference policy template which helps apply the key requirements for open-source compliance

These resources will act as a guide in getting started planning and implementing the changes. As every organisation operates individually in different ways, there is no set method to becoming compliant, however, OpenChain has set out the goals which act as an end destination, making it easier to develop a path there.

Conclusion

Now that you know what OpenChain is, and how to become open-source licence compliant, why should you do this? What are the benefits? You can gain a greater understanding of the software you are using in your code. This makes it easier to upgrade and maintain, reducing the risk of vulnerabilities. It can highlight the risks and costs of the open-source software you are currently using and can draw attention to the ones that are most important (e.g. packages that need attention now - that are out of date and causing security risks). Additionally, a greater understanding of the licences you are using, and how you are using them, reduces the risk of not complying with the terms set out in the open-source licence, meaning less legal risk.

Update: 2024-08-14 - Charlotte Gayton presented a Linux Foundation Webinar for the OpenChain Project covering an overview of her industrial placement implementing OpenChain ISO/IEC 5230 and her final year project on OpenChain ISO/IEC 18974.