SPDX 3.0 — a new version of the widely used SPDX bill of materials specification — was released on April 17, and it includes several significant changes from the prior 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 scenarios like AI and data. Profiles can also be used to provide more transparency into the software build process. Additionally, SPDX 3.0 documents 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.
“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 was originally published in July 2023, 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.
The post was updated on April 17, 2024, following the official release of SPDX 3.0
SPDX 3.0 Profiles
From open source license compliance to security and plenty in between, there are 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 five new profiles in SPDX 3.0:
Licensing: This profile includes many of the licensing-related data fields from the prior SPDX 2.3, but with a few adjustments. For example, the SPDX 3.0 licensing profile adds a “custom exceptions” data field. (License exceptions “grant an exception to a license condition or additional permissions beyond those granted in a license.” The prior SPDX 2.3 has a defined exception list.)
Notably, there are a few versions of licensing profiles in SPDX 3.0. The Licensing Profile "defines a minimum set of license information to facilitate compliance with typical license use cases." Additional licensing metadata can be found in the "Simple Licensing" and "Expanded Licensing" profiles.
Security: The security profile includes fields to link to external security documents like CSAF (Common Security Advisory Framework (CSAF) and CVEs. The profile 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). It also supports vulnerability assessments like EPSS, CVSS, and SSVC.
Build profile: This includes data fields related to the software build. It covers data like the build start time, end time, environment, and 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 captures metadata related to the "outputs of the AI development process, such as software packages, models, and datasets.” Examples of new data fields available in the AI profile are:
- UseSensitivePersonalInformation: If personal information (such as biometric or address data) is used to train an AI model or during the inference
- InformationAboutApplication: A data field used to describe how the model is used in software, such as "pre-processing steps, third-party APIs, and other pertinent details"
- EnergyConsumption: This field describes any number of resources used, including (but not limited to) computational resources used, training time, type and quantity of processing units, and more
Dataset Profile: As the name suggests, this profile is intended to communicate information about datasets. The 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.
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 coincides 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.
Creator Information, Name Change, and More
SPDX 2.3's "creator" data field communicated the person, organization, or tool used to produce the bill of materials. In SPDX 3.0, that has been replaced by "createdBy" and "createdUsing" properties. The "createdBy" field describes the person or organization producing the bill of materials, while the "createdUsing" field communicates the tool used to create the BOM. (The "createdBy" field is required in SPDX 3.0.)
Another change is that the full name of the SPDX specification has changed to System Packet Data Exchange (which speaks to the growing number of use cases the standard supports). It was formerly Software Data Package Exchange.
For a more full list of changes in SPDX 3.0, we recommend you visit the specification's annex on the topic.
Beyond SPDX 3.0
Work on SPDX 3.0 didn't prevent 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 the SPDX SBOM format — and for step-by-step guidance on generating an SPDX SBOM with FOSSA’s free product — check out our complete overview of the standard.
