by Jeff Shapiro & Gary O’Neall
SPDX 3.0 Mini Summit OSSNA 2023 🇨🇦 blog post series
This post is a bit of an oddball because, technically, this talk did not take place during the SPDX mini summit. It was part of Supply Chain Security Con hosted at OSSNA 2023. But since it’s completely on brand and, most importantly, aligned with the mini summit’s goals, it was worth publishing in our blog.
The primary goal of the SPDX 3.0 Mini Summit was to announce and highlight the advancements encompassed in the SPDX 3.0 release candidate (read about it in detail here). This new iteration is poised to bring significant enhancements to the way organizations create, manage, and interpret Software Bill of Materials (SBOMs), offering a more streamlined and effective means of tracking and managing software components. In line with the SPDX project’s mission: “The mission of SPDX is to develop and promote open standards for communicating SBOM information, including provenance, license, security, and other related information.”
In addition, the summit spotlighted the introduction of SPDX profiles, a mechanism to tailor SPDX documents for specific use cases, thereby increasing their flexibility and usability across various domains like software builds, ML and AI, security and many more to come. In essence, the event was an impactful leap toward fostering better transparency, security, and efficiency in software supply chains, reinforcing the importance of SBOMs in the modern software landscape.
Get started with SPDX with Gary and Jeff
In the ever-evolving landscape of software development and cybersecurity, understanding and implementing Software Bill of Materials (SBOMs) has never been more critical. Offering an exhaustive inventory of all components used in a software product, an SBOM serves as the cornerstone of managing software vulnerabilities and ensuring license compliance. This significance was emphasized in a recent talk by Jeff Shapiro from the Linux Foundation and Gary O’Neill from Source Auditor, where they demystified the intricacies of SBOMs, offering a comprehensive primer on how to read, use, and generate these vital documents.
The first thing they highlighted was the definition of an SBOM, described as a “nested inventory” or a “list of ingredients” that forms an application, service, or package. Starting with specifications provided by the National Telecommunications Information Administration (NTIA), they emphasize that an SBOM is essentially a catalog of everything that goes into your software product, right from source files and libraries to packages and binaries. They underlined the importance of SBOMs being both human-readable for understanding and machine-readable for tool-generated processing, encapsulating everything from basic component information like the author, package name, and version, to detailed provenance information. They then demonstrated several examples of SBOMs using the SPDX format from simple “one page” SBOM’s to SBOM’s that include more complex dependency and source information.
An SBOM Primer: From Licenses to Security, Know What’s in Your Code, or Someone Else’s!
In this talk, both Gary and Jeff talk at length about the multitude of tools that are available within the SPDX ecosystem and the role they play in not only generating but consuming SBOMs and more. They emphasize that while build tools that integrate directly into development workflows are ideal for generating SBOMs, there is also a need for tools to handle software that comes without an SBOM. Such tools fall into three broad categories: those that inspect build metadata, those that scan individual files (typically for license information), and source snippet scanners.
They start by highlighting the importance of integrating SBOM tooling into the build process, as it provides comprehensive visibility into the software components used and produced. Tools such as Maven and Gradle plugins, a GitHub action from Syft, and an SBOM generator developed by the SPDX community can help generate SBOMs directly during the build process.
However, there are times when you might receive software that does not come with an SBOM. In such cases, they give examples of three categories of tools that can be used to generate an SBOM. Firstly, there are tools that analyze the build metadata from build artifacts such as Maven POM files, Gradle files, and others. These tools can be useful for identifying dependencies, although they might not provide much insight into individual source files.
The second category of tools scan files at the individual level, typically searching for strings that can provide information about licensing. While these tools might not be able to identify the specific packages or versions used, they can be useful for the licensing aspects of SBOMs.
The third category is source snippet scanners, which maintain extensive databases of known open source files. These tools inspect the source code you’re working with and try to identify which version and package it corresponds to by comparing it against their databases. While this method can generate a lot of false positives, it can provide valuable information for SBOMs if the results are reviewed by a human.
While many tools, both open source and commercial, are excellent at performing one or two specific tasks, they point out that there are currently few, if any, tools that excel across all areas. The industry is still waiting for comprehensive tools that are equally adept at analyzing source code, identifying dependencies, scanning for known vulnerabilities, and handling other aspects of SBOM creation.
SPDX 3.0 to the rescue
As Gary and Jeff close this talk, it’s worth restating the challenge and opportunity that lies ahead. The software supply chain industry needs comprehensive tooling that excels in every aspect, from thorough source code analysis and precise dependency identification to efficient scanning for known vulnerabilities. We believe that SPDX community’s combined expertise and collective creativity can transform this vision into reality. This is where SPDX 3.0, now in its final stages as a release candidate, comes in as the perfect platform to achieve this industry-wide solution.
SPDX 3.0 release candidate is a call to action for developers, architects, security specialists, and those who are passionate about open source software. You have the chance to shape the future of SPDX, and by extension, the future of the software supply chain industry. By contributing to SPDX 3.0, you can help combat security vulnerabilities, ensure license compliance, and enhance software supply chain transparency. This is an open invitation for you to join us in this exciting endeavor. The industry, the community, and the world are waiting to see what we can achieve together. Let’s shape the future of our software supply chains by contributing to SPDX 3.0, making it.
