Software today is built on a combination of open source and proprietary software packages. Developers can reuse and build on the packages created by others, which results in the rapid creation of new capabilities and technologies.
Related: How SBOM factors into DevSecOps
This reuse creates dependencies, all of which don’t necessarily stay updated at the same pace. The accurate and authenticated identification of all the relevant software package dependencies is key to preventing software supply chain attacks.
Agreeing on a standard way of cataloging summary information about the packages and their dependencies is necessary for multiple tools to interact efficiently and keep up with the rapid pace of reuse.
History of SPDX
We started the Software Package Data Exchange® (SPDX®) project in 2010. The project had the simple goal of sharing summary information about a software package between the creator and consumer. At that time, to comply with the licenses in open source, you had to find them in the source code.
This resulted in hours of issuing grep commands or working with commercial source scanning tools, and once you had the details, you didn’t have a good way of sharing them.
After comparing notes and recognizing there was a group of managers, lawyers, and developers frustrated by the same problem, we started a grassroots collaborative effort hosted at the Linux Foundation to agree upon and standardize the information we wanted to share about software. We needed to capture the known information about open-source software and proprietary software, as products are created from both.
Fast forward ten years. The SPDX specification had gone through many versions and collected enough use cases, and the team felt it was ready to go forward for broader international review. In particular, for the two years prior, project contributors had been actively participating in the NTIA Software Bill of Materials (SBOM) multistakeholder process to define what a minimum set of fields should be for an SBOM. The SPDX 2.2 specification implemented all the recommended changes from that process.
ISO requires specific formatting, we made the changes and sent 2.2.1 for their feedback. We went this route partly because ISO standardization helps to give procurement departments in large and small organizations greater certainty about having a standardized and straightforward way of communicating this SBOMs information. Having a formal ISO standard is also helpful to organizations that wish to mandate compliance with the SPDX standard in contracts and RFPs.
SPDX as an ISO standard
It’s not just companies adopting SPDX now; open source projects have been standardizing on it as well. Popular open source projects such as Kubernetes, Yocto, and Zephyr have all started enabling the ecosystem to generate SPDX SBOMs during builds automatically. This is possible due to the SPDX and other open source projects implementing tooling and libraries for different projects to use and incorporate into their own release and create workflows.
In a supply chain, we’re also going to need secure ways of sharing this information inside and between companies, and other initiatives are emerging to address this aspect. But the directives of world governments may push these initiatives forward sooner rather than later.
In May 2021, when the Biden Executive Order on Improving the Nation’s Cybersecurity emerged, SBOMs were referenced as a key technology to be adopted, and NTIA was directed to define minimum requirements for an SBOM after a 60-day feedback window.
The guidance provided by NTIA was independent of the ongoing SBOM Multistakeholder process but was based on it and feedback received from companies and other interested parties. SPDX 2.2 supports all of the minimum elements for an SBOM as articulated in that guidance to industry and many more use cases.
For the vision of improved cybersecurity to be realized, every time an executable image is created, an SBOM describing that image’s content should be generated simultaneously. SPDX provides a functioning, well-tested, and now internationally standardized means for communicating the information to help make this vision possible.
Now that SPDX 2.2.1 has been published as an ISO standard (ISO/IEC 5962:2021), it simplifies the task for software supply chain participants (both suppliers and consumers) to have an international standardized way of communicating summary information about software and its dependencies. The transparency about the software provided by an SPDX SBOM makes it possible to automate the monitoring of vulnerability databases and match up to the applications and their dependencies efficiently at scale.
About the Author: Kate Stewart is vice president of dependable systems at the Linux Foundation.
Title: GUEST ESSAY: How SPDX helps reconcile interdependencies of open, proprietary software
Sourced From: www.lastwatchdog.com/guest-essay-how-spdx-helps-reconcile-interdependencies-of-open-proprietary-software/
Published Date: Mon, 11 Oct 2021 12:11:15 +0000
Did you miss our previous article...