Table of Contents:
- OpenChain ISO 5230
- OpenChain ISO 5230 in M&A
- OpenChain ISO 5230 in Procurement & Outsourced Development
- Open Source at Scania
- The SBoM
- Regulating the Risks
- Get Ahead of the Curve
- Sources
OpenChain Background
In 2013 the Linux Foundation started the OpenChain Project led by Shane Coughlan. The project sought to define an effective specification for open source license compliance throughout the software supply chain.
In December 2020 OpenChain was ratified and published as an international standard: ISO/IEC 5230:2020. Therefore, ISO/IEC 5230:2020 and the Open Chain specification are functionally identical.
The standard defines the key requirements of a quality open source license compliance program, which builds trust between organisations exchanging software solutions composed of open source software.
This ‘trust’ is founded on the fact that an organisation’s conformant program indicates to others that it has been designed to achieve license compliance for the open source software it shares.
Microsoft announced its conformance to the OpenChain ISO 5230 standard back in 2019. Many other organisations have also publicly announced OpenChain conformant programs including Arm, Cisco, Siemens and Uber.
OpenChain ISO 5230 is a flexible standard that can be integrated into various workflows. For example, the standard can be leveraged as a requirement in the merger and acquisition (M&A) due diligence process and for the supply chain of software services
OpenChain ISO 5230 in Mergers & Acquisitions (M&A)
During the M&A process, legal teams carry out technical due diligence against the target organisations software. This process assesses the risk associated with the organisation deriving from its software. At the pre-deal stage venture capitalists and other investors also carry out technical due diligence against the investee for the same reasons.
As part of this assessment, the target organisation will need to demonstrate the amount of control, they have over their use of open source software. Following this assessment terms may be put into the contract to mitigate any risks.
The OpenChain ISO 5230 standard will play a growing role in M&A transactions because of the widespread adoption of open source software, the growing number of transactions in the technology sector and the fact that more and more organisations who do not regard themselves as technology businesses effectively are. This is because every day companies are hiring software engineers to develop solutions or are outsourcing solutions to transform their business practices and to improve customer satisfaction.
Conformance to the OpenChain ISO 5230 standard has the potential to reduce friction in these transactions. This is because a lot of the information required during the due diligence process will be ready to hand. Therefore, using the OpenChain standard requirements as part of the due diligence process provides a clear picture of the target organisation and any risks posed by open source software, to the purchaser or investor.
At Source Code Control Ltd we are increasingly seeing investors requiring that investee’s become OpenChain ISO 5230 conformant as a condition of ongoing investment. Conformance to the OpenChain ISO 5230 standard is a great governance mechanism to ensure that the investee is not veering off the path of open source license compliance before the investor exits.
OpenChain in Procurement & Outsourced Software Development
The OpenChain ISO 5230 standard was designed for procurement and outsourcing activities where software is involved, and where the products or solutions will be applied to business-critical areas or sold.
Using the OpenChain ISO 5230 standard in a typical procurement and outsourcing workflow quickly identifies which companies are aligned around industry-wide open source compliance best practices and which are not.
When a supplier conforms to ISO/IEC 5230:2020 this provides various assurances:
- This company has an open source policy
- Their relevant staff have completed open source software training
- They have a process for addressing compliance in inbound software
- They have a process for addressing compliance during internal development
- They have a process for addressing compliance for outbound products and services
- They have documentation on how this is accomplished
- Everything is structured in the same manner as every other company using this industry standard
OpenChain conformant organisations gain a competitive advantage in the sales process for their solutions. For example, a company issues a request for proposal (RFP) to acquire a software solution. The procurement organisation short lists suppliers. If one of the suppliers is OpenChain conformant they are demonstrating they are managing their supply chain and not passing on a risk. On top of that they can supply an accurate Software Bill of Materials (SBoM). If the other shortlisted organisations are unable to demonstrate this, there will be a question mark over the quality of their software development processes. This is a demonstration of the objective of OpenChain in building trust in software supply chains. This could be looked at from the acquirer of software solutions viewpoint. OpenChain is one of the benchmarks they can use to vet suppliers for supplying trustworthy solutions.
Open Source at Scania
OpenChain ISO 5230 was designed to be used in the software procurement process across many industries, and now we are starting to see how the ISO standard will be used going forward.
In May 2021, Scania announced a big improvement to the professional management of their outsourced software solutions. Scania has clearly defined its expectations when open source is part of a delivery.
A corporate standard has been issued which mandates that suppliers must conform to ISO/IEC 5230:2020. Conformance allows Scania to trust that their suppliers have a professional management program in place, for their use of open source software.
If in the process of developing a solution for Scania, a supplier makes modifications to open source components, Scania specify they would like to see those modifications contributed to the open source project. This process is known as upstreaming. Upstreaming encourages participation in open source projects which increases innovation through collaboration and ultimately strengthens the original open source project.
Finally, Scania asks that suppliers provide any Software Bill of Materials (SBoM’s) in the ISO/IEC DIS 5962 (SPDX) format. SPDX is an open standard for communicating an SBoM. This format eliminates unnecessary work efforts by providing a common format for companies and suppliers to share open source software composition data between teams or a along a supply chain.
Jonas Öberg, Open Source Officer at Scania says:
“We would love to see more suppliers adopt OpenChain to secure Open Source use in the supply chain.”
This is an exceptional and impactful development for OpenChain and open source compliance, which will likely permeate throughout the rest of the VW Group, become a standard throughout the automotive sector and across many more industries.
The Software Ingredients – SBoM
An SBoM is a formal record of components and their associated licenses in a piece of software. It is analogous to a list of ingredients on food packaging. An SBoM identifies and lists software components, information about those components and the relationships between them.
They allow the builder to easily determine whether components within a piece of software are up to date and to monitor version management. Version management is essential to assess whether the software is at risk of an exploitable vulnerability. They can also be used to perform license analysis and make identifying license obligations much easier.
In 2010, the Linux Foundation launched the SPDX (Software Package Data eXchange) project to create a standard format for communicating the components, licenses and copyrights associated with software packages. The specification is now under version 2.2 and currently under development with the International Organization for Standardization and will soon become an official ISO standard: ISO/IEC DIS 5962.
OpenChain ISO 5230 is a management process to achieve open source software license compliance. The SPDX ISO standard works as a complementary standard to provide a format for organisations to follow, to achieve said license compliance.
The purpose of the SPDX project was to create a set of data exchange standards that enable companies and organizations to share human-readable and machine-processable software package metadata to facilitate software supply chain processes. This saves time and facilitates accuracy. A project such as this is invaluable as accurate identification of software is key for the supply chain process. As mentioned previously, Scania asks that suppliers provide any SBoM’s in the ISO/IEC DIS 5962 (SPDX) format.
There is a need for such a common format because development teams across the globe use the same open source packages, but little infrastructure exists to facilitate collaboration on the analysis or share the results of these analysis activities. As a result, many groups are performing the same work leading to duplicated efforts and redundant information.
Regulating the Risks
There have been a number of regulations issued by industry and governmental bodies to regulate the use of open source software to better mitigate and manage its associated risks. Like ISO/IEC 5230:2020, many of these regulations expressly require the production and delivery of a software bill of materials.
On the 12th of May 2021, the White House issued an executive order to improve the nation’s cybersecurity. It included the following:
The executive order guides buyers of software solutions to request an SBoM for each product. Software solution providers are being guided to supply an SBoM for each product. A fundamental requirement of OpenChain ISO 5230 is to identify the third party components in a software solution. Therefore, this standard is complementary to the Executive Order.
The National Telecommunications and Information Administration (NTIA), for the United States Department of Commerce, advocate for an open and transparent process in the software supply chain. The NTIA say the reality is this:
“When a new risk is discovered, very few organizations can quickly and easily answer simple, critical questions such as: “Are we potentially affected?” and “Where is this piece of software used?” This lack of systemic transparency into the composition of software across the entire digital economy contributes substantially to cybersecurity risks as well as the costs of development, procurement, and maintenance.”
The SBoM is the NTIA’s solution. The use of SBoM’s allows earlier identification (and mitigation) of potentially vulnerable systems, supports informed purchasing decisions, incentivizes secure software development practices and will save hundreds of hours in risk analysis, vulnerability management and remediation process’.
In 2020, ENISA (European Union Agency for Cybersecurity) published ‘Guidelines for Securing the Internet of Things (IoT) – Secure Supply chain for IoT’. The publication looks at the different stages of the development process, explores the most important security considerations and identifies good practices to be taken into account at each stage.
Particularly, the guidelines recommend scanning products to identify the open source components and vulnerabilities within the product. The guidelines also recommend producing a Software Bill of Materials.
Get Ahead of the Curve
Open source software license compliance must not be overlooked. Following the trends in the use of ISO/IEC 5230:2020, it is fair to predict more companies and industries will demand conformance as well as integrate the standard into their supply chain work practices.
Cybersecurity breaches are a serious threat to all types of businesses. In the last twelve months four in ten businesses report having cybersecurity breaches or attacks in the UK. Although ISO/IEC 5230:2020 does not contain an express provision regarding cybersecurity, conformance to the standard makes the tracking of security vulnerabilities much easier.
Adherence to the ISO standard now, puts your organisation ahead of the curve and places you ahead of non-conformant competitors.
If this article raises questions or concerns Source Code Control can provide you with support and guidance. Visit our website here or contact us at [email protected]
Sources
The sources used for this article are listed here:
- ISO/IEC 5230
- Open Chain Project
- SPDX Project
- Andrew Katz, Open Source in M&A and OpenChain