(This post was first created in September 2023 and updated in April 2024 after SPDX3.0 official release).
SPDX is one of the three SBOM specifications recommended by NTIA/CISA.
On April 16th, the SPDX team officially released SPDX version 3.0.
In a massive leap from SPDX2.3, this version packs a lot of features that cover new SBOM use cases and simplify existing capabilities.
Let's' dig in.
SPDX 3.0 flexibility is contained in a new abstraction called Profile.
SPDX Profiles describes a specific use case for the SPDX document. For instance, a Security Profile is usable by product security specialists, while representatives of legal and compliance teams analyze a Licensing profile.
Therefore, an SBOM only applicable to a specific use case can choose not to fill in the details applicable to a different Profile.
To achieve this, SPDX fields from version 2.3 (with some changes) are segmented into three groups:
Each Use-Case Profile comes with its Profile Conformance Point, essentially declaring the required fields for that specific Profile.
An SPDX document can include multiple profiles together, simplifying the need to have multiple SBOMs populated with different fields for various stakeholders
Examples:
SPDX3.0 starts with six use cases covered with its profiles:
Security, Licensing, AI, Data, Build, Lite
The Security Profile is designed to communicate the discovery and disclosure of vulnerabilities, their severity, impact, exploitability risks, and remediation plans.
While SPDX 2.3 provided a mechanism for linking with external vulnerability data using external reference property, SPDX 3.0 supports Security Profile to embed fast-changing vulnerability data from the software composition stored as Software Profile.
Security Profile includes Vulnerability elements to detail specific details such as ID, summary, external references, etc., along with a new set of fields to convey CVSS2, CVSS3, CVSS4, and SSVC vulnerability assessments.
It also adds fields to embed or link EPSS or Exploitability, (especially useful for recording CISA KEV’s exploitability) and external security information such as security advisory, reference to patch, or any custom security information.
This profile is the closest thing to SPDX2.3 and broadly covers licensing and copyright fields from SPDX2.3. The underlying Model has been updated to fit the 3.0 model, and in the process, fields have been made consistent across different types of artifacts — Package, File, and Snippets.
SPDX 3.0 also adds the ability to get custom license exceptions added as license additions. For example MIT WITH AdditionRef-My-Own-Custom-Exception is a valid license addition only in SPDX 3.0.
SPDX 3.0 supports building an SBOM for AI applications with the AI Profile.
This profile includes inventory components, dependencies, other AI-specific references, and security and ethical considerations associated with the application.
The AI Profile includes fields to disclose the attributes and behavior of the underlying Model, such as model architecture, size, required resources, including computational and energy usage, model limitations, model data preprocessing techniques, and model explainability.
The AI Profile also includes security considerations but uses the EU general risk assessment methodology and the EU AI Act’s risk assessment.
To work alongside AI, SPDX Data Profile (called Dataset in the schema model), in turn, focuses on fields to describe attributes and behavior of the underlying training and test data, such as data collection processes, size, data noise, sensors producing the data, intended use, known biases, sensitivity indicator, anonymization method in use, and confidentiality of the data.
The Data Profile is intended for use by Data Scientists, engineers, and Governance Officers to understand the type of data in use, associated compliance and regulatory risks, and design systems resilient to Data posing techniques.
This is another new set of fields to convey the product's build-specific information. The profile aims to improve the builds' security, reproducibility, and auditability. The profile derives inspiration from SLSA and reproducible builds. It can capture details such as build-id, start and end times, environment, arguments, build tools and versions, build steps in a pipeline, and hashes of the artifact, among others.
Sometimes, a software component revision is generated with specific conditions such as — a hot-fix or based on conditional enabling of features with a change in underlying terms and conditions. These potentially temporary revisions serve as a stop-gap between the regular release cycle and, therefore, could come with its validity dates.
Usage Profile in SPDX3.0 addresses this specific set of use cases by providing fields for disclosing intended usage, license conditions, build conditions, test conditions, and validity dates. This profile can also help distinguish internal builds, such as builds during prototyping and unrestricted testing.
One of the goals of SPDX3.0 has been to simplify the specification and extend it to a more extensive set of use cases. SPDX Profiles above is an example of simplification that breaks down an SDPX document by use cases and requires only filling in values applicable to the specific profile (e.g., Security use cases vs. Licensing use cases).
In addition, a few other changes have been made to SPDX3.0 that aim to address the shortcomings of SPDX2.3:
Field Namespace
SPDX3.0 introduces a namespace to identify fields specific to a given use case. For instance, Core use cases are under the namespace Core, AI use cases are under AI, and detail license use cases are under ExpandedLicenses. This enables implementors and auditors to focus on fields in the area of their use case.
Element Imports
SPDX 2.3 uses ExternalDocumentReferences to connect one SPDX document to a different SPDX document. With 3.0, the functionality has been extended to reference Element external documents directly using a combination of Namespace and Imports. This enables the use case of frequently generated small Element SPDX documents referenced from less frequently generated SPDX metadata documents. A referenced use case was to generate snippet SPDX with each pull request as Element, as the original repository is being tracked with full SBOM.
PURL
PURL or Package URL has been elevated to a top-level property, simplifying component identification.
Agent
A new class Agent encapsulates anything that can act on a system, such as a Person, Organization, or software tools. Therefore, Creator and Supplier properties from SPDX 2.3 are safely replaced with an Agent.
JSON Pluralization
SPDX 2.3 had arrays represented as pluralized strings (e.g. externalRefs ). With 3.0, SPDX will move to consistent field names between RDF and JSON.
SPDX 3.0 still invites input and feedback on the specification, and the SPDX team’s mailing list or Github repository is the best way to reach the team.
Interlynk is actively researching and building tools for both SPDX and CycloneDX ecosystems, and we are happy to answer any questions you might have. Feel free to reach out to us at hello@interlynk.io or via interlynk.io
