SPDX 3.0 — a new version of the widely used SPDX bill of materials specification — is in the works, and it’s expected to include several significant changes from the current v2.3.
These include the introduction of new “profiles,” which aim to better serve specific SBOM use cases like open source license compliance and security as well as emerging SBOM scenarios like AI and data. Profiles can also be used to provide more transparency into the software build process. Additionally, SPDX 3.0 documents will have a different structure with more built-in flexibility than the current 2.3.
“SPDX 3.0 is a major upgrade to the specification,” SPDX tech team co-lead Gary O’Neall told FOSSA during a recent webinar. “Some of the drivers and enhancements you’ll find are in areas like simplification — we’ve gotten feedback that if all someone cares about is security, they don’t want to have to learn all the licensing information. If all they care about is licensing, they don’t want to learn about security. So we’re introducing the concept of profiles. When the 3.0 is released you’ll be able to go into our website, select the profile you’re interested in, and only see the information for that profile.
“We’re also making some changes to make SPDX a lot more flexible. The biggest is that you no longer need to wrap everything around a document. What this enables is if you want to make a database of SBOM elements available over the internet, and you want to update them in almost real-time, you can set that up and comply with the SPDX specification. You can go all the way down to the very individual file or even just the individual relationship and make that available. And the standard has all of the linkages in there and the verification information to make that work. So it can be a lot more flexible, especially for online data access.”
Editor’s Note: This blog post is based on SPDX tech co-lead Gary O’Neall’s webinar with FOSSA in addition to two other recent presentations: Gary’s session at Open Source Summit North America 2023 and an OpenChain webinar with Alexios Zavras, SPDX Outreach Team Chair. We recommend you view those presentations along with this blog for an in-depth preview of SPDX 3.0.
SPDX 3.0 Profiles
From open source license compliance to security and plenty in between, there is a wide (and growing) variety of common SBOM use cases. Of course, not every organization or team will have the same purpose for creating or consuming an SPDX document.
For example, an in-house legal team may care a lot more about licensing than the nuances of an AI model. A security team will likely be particularly interested in vulnerability exploitability information like that in VEX. And so on and forth.
Profiles allow software suppliers to produce simpler and more tailored SPDX SBOMs for the use cases they and their customers care about most.
There are six new profiles in SPDX 3.0:
Licensing: This profile includes many of the licensing-related data fields from the current SPDX 2.3, but with a few adjustments. For example, the SPDX 3.0 licensing profile is expected to add a “custom exceptions” data field. (License exceptions “grant an exception to a license condition or additional permissions beyond those granted in a license.” The current SPDX 2.3 has a defined exception list.)
Security: The security profile includes fields to link to external security documents like CSAF (Common Security Advisory Framework (CSAF) and CVEs. The proposal also adds the ability to embed certain minimum elements to convey security information, such as VEX (Vulnerability Exploitability eXchange) status justifications (i.e. if a product is deemed to be not affected by a vulnerability, an explanation of why that is the case).
Build profile: This includes data fields related to the software build. It covers areas like the build configuration file and build type (tools or infrastructure the build was invoked on). The build profile provides the necessary information to verify the software build provenance and ensure that the provided software is what it claims to be.
AI: The AI profile aims to communicate information that will be “useful for AI applications and models.” Examples of new data fields available in the proposed AI profile are “Sensitive Personal Information,” “Energy Consumption,” and “Data Preprocessing Steps,” among others.
Dataset Profile: This profile is intended to communicate information about a dataset “used in a software or to train/test an AI package.” The proposed profile includes fields like “Dataset Type” (such as images, text, or multi-modal), “Dataset Size” (measured in bytes), and “Dataset Availability” (whether the dataset is available for public download or gated behind a form) among others.
Usage Profile: Not every piece or version of software is intended for general availability. The Usage Profile is designed to help producers distinguish between software at different stages, such as design, prototype, and testing.
Other Changes in SPDX 3.0
Although the addition of new profiles is one of the highlights of SPDX 3.0, it’s not the only change from SPDX 2.3. Here’s a look at some of the other major differences.
Document Structure
The introduction of new profiles in SPDX 3.0 will coincide with a new required data field that communicates which profiles your SBOM describes.
SPDX 3.0 is structured in such a way that these new profiles are stacked on top of the SPDX Core Model — which includes foundational data fields like document creation information — and, in many cases, the SPDX Software Profile. (The Software Profile includes familiar data fields like package version, package URL, declared license, and concluded license, among others.)
SPDX 3.0 documents must include the Core Model and will likely include the software profile, but the other use case-specific profiles are optional. In other words, an SPDX 3.0 SBOM will be structured along the lines of:
- Core Model: Required
- Software Profile: Not required, but recommended for the vast majority of SBOMs
- Other Profiles: Use as needed
Relationships
SPDX relationships are a way of describing how elements relate to each other. For example, one package might be a dependency of another package.
In SPDX 2.3, an element (a package, file, or snippet) contains a list of relationships to other elements. If you want to add, remove, or modify a relationship, you have to create a new version of the element. Also, the relationships and the element containing the relationship must be included in the same SPDX document.
In SPDX 3.0, the relationship will be its own element rather than a property of another element. This allows you to add new relationships without having to replace the original elements. You can also create a new, separate “document” which introduces new relationships between previously defined elements — a common scenario when additional analysis is done for an existing SBOM.
Flexibility
In the current SPDX 2.3, producers are required to include all elements in an SBOM document to transmit it. This, of course, could become quite resource-intensive if you’re providing SBOM updates as part of a large automated build system where there is a high volume of small incremental changes. SPDX 3.0 will enable the SBOM producer to provide very granular bits of information, down to individual elements.
Beyond SPDX 3.0
The ongoing work on SPDX 3.0 hasn’t prevented the SPDX community from planning future improvements to the specification. This includes working groups dedicated to medical devices and services.
SPDX tech team co-lead Gary O’Neall discussed these groups’ progress and goals in our recent webinar.
“If you think about software that’s being used in medical devices, you want to make sure it’s safe,” O’Neall said. “This goes beyond the build and security environment that we’re doing in 3.0. If you want a medical device to be safe, with its software, you need to know what hardware it runs on and what the configuration is for the hardware, so we have some work going on in that area as well.
“And then one of the groups I’m leading is SPDX for services. This is based on a CISA group for service transparency. We’re basically taking the work that they’ve provided and making sure that if you’re using SaaS you can basically get a service BOM of the information and be able to use it to make sure you can trust the service provider that’s in there.”
For more information on SPDX — and for step-by-step guidance on generating an SPDX SBOM with FOSSA’s free product — check out our complete overview of the standard.
