Improving Open Source Supply Chain Transparency with SPDX – The New Stack

Publication of ISO/IEC 5962:2021 Standard for BOM software (SBOM) is more of a beginning than an end. At least that’s what I learned from an interview with Dr. David A. Wheeler at the time of this publication last summer.

Understanding this distinction and its implications in the IT world requires some experience in standardization, the logistics perspective of software, and the Linux Foundation, where Wheeler is director of open source supply chain. Here is the summary of how these pieces fit together:

Security at the center

SBOM is a serious subject, in the sense that it is not only debated by do-it-yourselfers and theoreticians, but also by presidential staff and military policy makers.

Cameron Laird

Cameron is vice president of Phaseit, Inc., where he implements software projects and publishes articles on the results. A long-time developer, manager and author, he has recently focused on the architectural challenges of “everything continuous”: continuous integration, continuous testing, etc.

More specifically, US President Biden Executive Order 14028 on improving cybersecurity (EO14028) recognized the management of SBOM as an urgent national security concern.

How does an esoteric corner of computing – that’s what SBOM is – land in the spotlight of global attention?

The Biden administration’s executive order was undoubtedly caused by the SolarWinds attacks in March 2020 and various high-profile infrastructure attacks against energy providers, such as Colonial Pipeline in 2021. However, the most recent notable example is a vulnerability in the Apache Software Foundation Log4j Software. The vulnerability, CVE-2021-44228 aka Log4Shell, can allow complete control of an unpatched system by an attacker.

As with the Heartbleed Incident affecting the OpenSSL library almost exactly 10 years ago, Log4Shell is a serious vulnerability affecting many systems. In the case of Log4j, this represents potentially billions of systems.

The response to the vulnerability was swift. Repair crews rushed into action. Fixes were developed quickly. Leaders ordered round-the-clock workers to replace vulnerable versions of Log4j and restore the Internet to its proper security baseline.

But as in 2012 with HeartBleed, with Log4j, organizations do not necessarily know where the affected components are located in their applications.

It sounds simple. The software components were broken, so specialists have to update the software components, right?

But not all fixes are as simple as replacing a single software component. However, modern software is built on very many components. Just as an automobile can be assembled in Tennessee from parts made in a thousand other factories around the world, software is built on top of other software, and that software is built on top of other parts. And so on.

Heartbleed responders in 2012 quickly discovered that while they wanted to replace and fix vulnerabilities, simply locating all SSL usage was a gargantuan and possibly unachievable task. Does specific software rely on the specific SSL library vulnerable to attack? Part of the shock of 2012 was finding out how often the answer to that ‘yes/no’ question was ‘we don’t know’.

In 2022, the answers to “where are all our uses of Log4j?” look surprisingly similar.

The industry has collectively solved this problem with more technology: SBOMs described using Software data exchange (SPDX), the OpenChain Specification, and other standards, and software have helped reduce the component problem to a more manageable level.

As in any other field, standards-based solutions only solve problems when standards are met. Much of the impact of EO14028 relates to the requirements for SBOMs in government operations.

On one level, Wheeler points out, publishing an SPDX as an SBOM standard is “totally irrelevant”: individuals and organizations wishing to comply already know about the standard long before an official step such as publication, and organizations that choose to ignore the standard can continue to ignore it, however “official” it has become. What really matters is the use of the standard, not just the official publication.

Still, getting people to agree to use a format for SBOMs is a difficult challenge. And now that the SPDX format is a fully recognized format for SBOM documents by the ISO, this gives it greater credibility in the space, so Wheeler and others agree that some celebration is warranted.

The Linux Foundation already uses SPDX in some of its projects, such as the Zephyr real-time operating system, where SPDX SBOM Generation is now integrated into itsWhere is” Command line meta tool. Moreover, the Yocto project, a build from a source Linux distribution for custom system implementations, generates SPDX as part of its overall build process.

Standard processes

Understand that standardization is a difficult and sustained challenge. Acceptance of a serious standard like ISO/IEC 5962:2021 usually takes at least three years.

Standards bodies originally focused on basic hardware requirements such as bolt sizes and safety equipment materials. Eventually, high-value products, including pharmaceuticals, electrical components, and chemical raw materials, merited formal standardization. Now it’s software tour: Software plays such a crucial role in day-to-day operations that it pays to standardize it.

This is a sense in which ISO/IEC 5962:2021 is more of a beginning than an end: many other software technologies are likely to follow formal standardization paths.

In addition, there is a strategic aspect in this publication, at least for the LF, which supports SBOM generation with SPDX: the Linux Foundation seeks to build on the ISO/IEC 5962:2021 experience. Standardization itself can become more repeatable and manageable.

From a computing perspective, SPDX is another interesting specialized language designed to express dependency relationships, license inheritance, and other domain-specific details.

At the same time, and ultimately even more importantly, SPDX is just a warm-up to negotiating the legal systems that make powerful software possible. From this perspective, SPDX is less a construction of language and computing than a story of different forms of human collaboration taking at least three levels relevant to software development:

  • Recognition that software exists in a single environment rich with other software with a myriad of dependencies. It is widely estimated that only 10% of a new product’s software is unique or exclusive to that product; the overwhelming majority of any application’s functionality resides in common libraries that exist outside of the current product. Building a great app feels less like a heroic art production in a lonely attic and more like a big logistics company.
  • Standardization is itself a typically human activity with powerful consequences.
  • Smart observers of the SPDX story learn lessons to apply in the governance and management of other software technologies requiring standardization such as SVG, 5G, Notebooks and NoSQL.

The focus on cybersecurity and software supply chain issues by the LF and the Open Source Security Foundation (OpenSSF) is rather timely. These organizations recently participated in a interprofessional virtual meeting at the White House and shared their intention to work with the administration in the public and private sectors, with all the technological and software projects at their disposal.

SPDX is just one of dozens of projects sponsored by LF and OpenSSF, including best practices and training programs, but SPDX will be a crucial tool that organizations can use to better understand the components installed in their environments.

To learn more about SPDX, the Linux Foundation encourages organizations to attend its SPDX SBOM DocFest Community, which will be held virtually on January 27.

Characteristic image via Pixabay


Source link

Comments are closed.