Featured

The National Telecommunications and Information Administration (NTIA) recently asked for wide-ranging feedback to define a minimum Software Bill of Materials (SBOM). It was framed with a single, simple question (“What is an SBOM?”), and constituted an incredibly important step towards software security and a significant moment for open standards.

From NTIA’s SBOM FAQ  “A Software Bill of Materials (SBOM) is a complete, formally structured list of components, libraries, and modules that are required to build (i.e. compile and link) a given piece of software and the supply chain relationships between them. These components can be open source or proprietary, free or paid, and widely available or restricted access.”  SBOMs that can be shared without friction between teams and companies are a core part of software management for critical industries and digital infrastructure in the coming decades.

The ISO International Standard for open source license compliance (ISO/IEC 5230:2020 – Information technology — OpenChain Specification) requires a process for managing a bill of materials for supplied software. This aligns with the NTIA goals for increased software transparency and illustrates how the global industry is addressing challenges in this space. For example, it has become a best practice to include an SBOM for all components in supplied software, rather than isolating these materials to open source.

The open source community identified the need for and began to address the challenge of SBOM “list of ingredients” over a decade ago. The de-facto industry standard, and most widely used approach today, is called Software Package Data Exchange (SPDX). All of the elements in the NTIA proposed minimum SBOM definition can be addressed by SPDX today, as well as broader use-cases.

SPDX evolved organically over the last decade to suit the software industry, covering issues like license compliance, security, and more. The community consists of hundreds of people from hundreds of companies, and the standard itself is the most robust, mature, and adopted SBOM in the market today. 

The full SPDX specification is only one part of the picture. Optional components such as SPDX Lite, developed by Pioneer, Sony, Hitachi, Renesas, and Fujitsu, among others, provide a focused SBOM subset for smaller supplier use. The nature of the community approach behind SPDX allows practical use-cases to be addressed as they arose.

In 2020, SPDX was submitted to ISO via the PAS Transposition process of Joint Technical Committee 1 (JTC1) in collaboration with the Joint Development Foundation. It is currently in the approval phase of the transposition process and can be reviewed on the ISO website as ISO/IEC PRF 5962.

The Linux Foundation has prepared a submission for NTIA highlighting knowledge and experience gained from practical deployment and usage of SBOM in the SPDX and OpenChain communities. These include isolating the utility of specific actions such as tracking timestamps and including data licenses in metadata. With the backing of many parties across the worldwide technology industry, the SPDX and OpenChain specifications are constantly evolving to support all stakeholders.

Industry Comments

The Sony team uses various approaches to managing open source compliance and governance… An example is using an OSS management template sheet based on SPDX Lite, a compact subset of the SPDX standard. Teams need to be able to review the type, version, and requirements of software quickly, and using a clear standard is a key part of this process.

Hisashi Tamai, SVP, Sony Group Corporation, Representative of the Software Strategy Committee

“Intel has been an early participant in the development of the SPDX specification and utilizes SPDX, as well as other approaches, both internally and externally for a number of open source software use-cases.”

Melissa Evers, Vice President – Intel Architecture, Graphics, Software / General Manager – Software Business Strategy

Scania corporate standard 4589 (STD 4589) was just made available to our suppliers and defines the expectations we have when Open Source is part of a delivery to Scania. So what is it we ask for in a relationship with our suppliers when it comes to Open Source? 

1) That suppliers conform to ISO/IEC 5230:2020 (OpenChain). If a supplier conforms to this specification, we feel confident that they have a professional management program for Open Source.  

2) If in the process of developing a solution for Scania, a supplier makes modifications to Open Source components, we would like to see those modifications contributed to the Open Source project. 

3) Supply a Bill of materials in ISO/IEC DIS 5962 (SPDX) format, plus the source code where there’s an obligation to offer the source code directly, so we don’t need to ask for it.

Jonas Öberg, Open Source Officer – Scania (Volkswagen Group)

The SPDX format greatly facilitates the sharing of software component data across the supply chain. Wind River has provided a Software Bill of Materials (SBOM) to its customers using the SPDX format for the past eight years. Often customers will request SBOM data in a custom format. Standardizing on SPDX has enabled us to deliver a higher quality SBOM at a lower cost.

Mark Gisi, Wind River Open Source Program Office Director and OpenChain Specification Chair

The Black Duck team from Synopsys has been involved with SPDX since its inception, and I had the pleasure of coordinating the activities of the project’s leadership for more than a decade. In addition, representatives from scores of companies have contributed to the important work of developing a standard way of describing and communicating the content of a software package.

Phil Odence, General Manager, Black Duck Audits, Synopsys

With the rapidly increasing interest in the types of supply chain risk that a Software Bill of Materials helps address, SPDX is gaining broader attention and urgency. FossID (now part of Snyk) has been using SPDX from the start as part of both software component analysis and for open source license audits. Snyk is stepping up its involvement too, already contributing to efforts to expand the use cases for SPDX by building tools to test out the draft work on vulnerability profiles in SPDX v3.0.

Gareth Rushgrove, Vice President of Products, Snyk

For more information on OpenChain: https://www.openchainproject.org/

For more information on SPDX: https://spdx.dev/

References:

1. https://www.ntia.gov/files/ntia/publications/frn-sbom-rfc-06022021.pdf
2. https://www.ntia.doc.gov/files/ntia/publications/ntia_sbom_faq_-_april_15_draft.pdf
3. Section 3.1.1 “Bill of Materials” in https://github.com/OpenChain-Project/Specification/raw/master/Official/en/2.1/openchainspec-2.1.pdf
4. https://www.openchainproject.org/news/2020/02/24/openchain-spdx-lite-credit-where-credit-is-due

The OpenChain Q2 Mini-Summit will be held on the 14th of June at 14:00 UTC / 07:00 PST / 15:00 BST / 16:00 CEST / 19:30 IST / 22:00 CST / 23:00 KST / 23:00 JST.

This three-hour event will have two live collaboration sessions.

We will open with one hour for the OpenChain education work team. The focus will be on final review of the online course and a discussion of what education work we should do next. This will be lead by Balakrisha, chair of the education work team.

We will continue with a two hour live-editing session for the OpenChain ISO 5230 security usage reference document. The goal will be to have an output that can be immediately used by our community regarding application of OpenChain ISO 5230 in security contexts. This discussion will be lead by Mark, chair of the specification work team.

Everyone is welcome to the event and encouraged to attend. There is no registration or fee to access. Your thoughts and requests for additional activities during the event are also welcome.

Dial in:

• https://us02web.zoom.us/j/9990120120?pwd=NzVCaFE2L1RRRFZaSkk0dm8xdlplUT09

The OpenChain PARTNER Mini-Summit will be held on the 14th of June at 07:00 UTC / 00:00 PST / 08:00 BST / 09:00 CEST / 12:30 IST / 15:00 CST / 16:00 KST / 16:00 JST.
The two-hour Mini-Summit will start with a discussion about the customer journey, followed by presentations from partners, and end with an open discussion about setting client expectations.

Andrew Katz of Orcro will facilitate the customer journey discussion.

Our partner presentations will be:

• Gilles Gravier and Reza Alvavi from WIPRO
• Nicole Pappler from AlektoMetis
• Martin Callinan from Source Code Control

We will end with the roundtable on client expectations moderated by Shane Coughlan of the OpenChain Project.

Join without registration and for free via Zoom:
https://us02web.zoom.us/j/9990120120?pwd=NzVCaFE2L1RRRFZaSkk0dm8xdlplUT09

Synopsys has been announced as a global third-party certifier for OpenChain ISO 5230, the International Standard for open source license compliance. They join PwC and TUV SUD in providing such services.

“Establishing trust in open source is a continual journey with growing obligations,” says Jacob Wilson, Senior Security Consultant with the Synopsys Software Integrity Group. “Becoming an OpenChain 3rd party certifier allows Synopsys to promote the ISO/IEC 5230:2020 Standard and OpenChain community.”

“Welcoming Synopsys as a third-party certifier is an important milestone in two respects for the OpenChain Project,” says Shane Coughlan, OpenChain General Manager. “Firstly, they have exceptional reach to provide certification services to a worldwide customer base, and this will be beneficial for the both the OpenChain community and the broader open source market. Secondly, as the third entity providing such services, the OpenChain community now has significant freedom of choice when seeking vendor support.”

It is time to explore the results of our Q1 survey! At the bottom of this post you can download the full document. Let’s check out the highlights:

1. Engagement and satisfaction is rated as very good or (more frequently) excellent across the board. The vast majority of respondents believe that we are “Very Good” or “Excellent” in putting forward what we are doing and sharing our information – either the business value, conformance, reference materials, and our website. Most importantly, people see us as a community that is easy to engage with and easy to get help from.
2. Our conformance response revealed something interesting. About half of our respondents are primarily interested in something other than a private health of their compliance program or being listed publicly as having an OpenChain conformant program.This is worth digging into more (and we will), but some preliminary notes are:
   1. Feedback indicates that a relatively small percentage are seeking public announcements regarding conformance at this juncture, regardless of internal compliance activities. Their focus is instead on internal (or inter-supply chain) improvements and conformance. 
   2. We additionally have a number of companies engaging with OpenChain ISO 5230 with applications outside of our core scope of conformance for the purpose of license compliance. These include entities engaging for activities related to security, mergers and acquisitions, and other business processes. We knew this from participants on our calls and so on, but it’s interesting how many of our community participants appear to fit into this demographic.
3. About a third of respondents have used our online conformance web app, and those that have found it excellent in its ease of use, while about a third of respondents are not interested in getting more help conforming with OpenChain ISO 5230:2020 in the future. From other sources we have indications that this is due to two factors:
   1. People are using the specification directly for conformance or using our downloadable questionnaire.
   2. People are getting assistance from third parties such as participants in our partner program.
4. We asked broader questions in the survey than those related only to OpenChain. For example, we asked about tooling, software bill of materials and interoperability. The interoperability questions were framed around determining what is important to the community in the context of open source license compliance and interoperability around Software Bill of Materials and/or automation.  Respondents overwhelmingly expressed interest in greater interoperability for all tools and automation. This means supporting ingest and export of SPDX. It means greater interoperability between open source tooling as well as between open source and proprietary tooling.

Now we know what people want, it is time to make it happen.

You can expect the project as a whole to lean into supporting to diverse use-cases for OpenChain ISO 5230. You can expect the tooling group to lean into the interoperability question.

And…you are the community. Let’s get started!

Want To Check Out The Full Survey Results?

As recently noted by Jonas Oberg, Open Source Officer at Scania, OpenChain ISO 5230 and SPDX have been explicitly included in Scania Corporate Standard 4589 (STD 4589). This defines the expectations Scania has towards suppliers when they deliver a solution containing open source software.

Scania has three key considerations defined in STD 4589:

1. Suppliers should conform to OpenChain ISO 5230.
2. Suppliers should ideally contribute modifications to open source components to the originating open source project.
3. Suppliers should provide a software bill of materials in SPDX format and any applicable source code when the software license requires it.