GUEST TRIAL: How SPDX Helps Reconcile the Interdependencies of Open Proprietary Software


Software today is based on a combination of open source and proprietary software. Developers can reuse and build on packages created by others, resulting in the rapid creation of new features and technologies.

Related: How SBOM takes DevSecOps into account

This reuse creates dependencies, which do not necessarily all stay updated at the same rate. Accurate and authenticated identification of all relevant software package dependencies is essential to prevent software supply chain attacks.

Agreeing on a standard method of cataloging summary information about packages and their dependencies is necessary for multiple tools to interact effectively and keep pace with the rapid pace of reuse.

SPDX History

We launched the Data Exchange® software package (SPDX®) project in 2010. The simple objective of the project was to share summary information on a software package between the creator and the consumer. At that time, to respect open source licenses, they had to be found in the source code.

This resulted in hours of issuing grep commands or working with commercial source analysis tools, and once you had the details you didn’t have a good way to share them.

After comparing our notes and recognizing that there was a group of managers, lawyers and developers frustrated with the same issue, we launched a local collaborative effort hosted at the Linux Foundation to agree and standardize the information we wanted to share about software. We needed to capture the known information about open source software and proprietary software, because products are created from both.


Fast forward ten years. The SPDX specification had gone through many releases and collected enough use cases, and the team felt ready to move forward for a broader international review. In particular, during the previous two years, project contributors had actively participated in the NTIA Software Nomenclature (SBOM) multi-stakeholder process to define what should be a minimum set of fields for an SBOM. The SPDX 2.2 specification implemented all of the recommended changes from this process.

ISO requires specific formatting, we have made the changes and sent 2.2.1 for their comments. We have chosen this path in part because ISO standardization helps give procurement departments in organizations large and small with greater certainty that there is a standardized and simple way to communicate this information on SBOMs. Having a formal ISO standard is also useful for organizations that wish to require compliance with the SPDX standard in contracts and tenders.

SPDX as ISO standard

It’s not just companies that are adopting SPDX now; open source projects have also standardized it. Popular open source projects such as Kubernetes, Yocto and Zephyr have all started to allow the ecosystem to automatically generate SPDX SBOMs during builds. This is possible thanks to the SPDX and other open source projects implementing tools and libraries for different projects to use and integrate in their own version and create workflows.

In a supply chain, we’re also going to need secure ways to share this information within and between companies, and other initiatives are emerging to address this aspect. But directives from world governments can move these initiatives forward as soon as possible.

In May 2021, when the Biden Executive decree on improving the nation’s cybersecurity emerged, SBOMs were referenced as a key technology to adopt, and NTIA was tasked with defining the minimum requirements for an SBOM after a 60-day feedback window.

The advice provided by NTIA was independent of the SBOM’s ongoing multi-stakeholder process, but was based on it and on feedback received from businesses and other interested parties. SPDX 2.2 supports all of the minimum elements of an SBOM as outlined in this industry guide and many other use cases.

For the vision of enhanced cybersecurity to be realized, each time an executable image is created, an SBOM describing the contents of that image must be generated simultaneously. SPDX provides a functional, well tested and now internationally standardized way to communicate information to make this vision possible.

Now that SPDX 2.2.1 has been released as an ISO standard (ISO / IEC 5962: 2021), it makes it easier for software supply chain participants (both vendors and consumers) to have an internationally standardized way of communicating summary information about software and its dependencies. The software transparency provided by an SPDX SBOM can automate the monitoring of vulnerability databases and effectively match applications and their dependencies at scale.

About the Author: Kate Stewart is Vice President of Trusted Systems at Linux Foundation.

*** This is a Syndicated Security Bloggers Network blog by The last watchdog written by bacohido. Read the original post on:


Leave A Reply