SBOMs and SPDX: Now and in the future

Using SPDX to track security vulnerabilities

SPDX 2.3 supports several important elements relevant to security. To identify a security vulnerability, you need to uniquely identify the specific version of the package. SPDX 2.3 packages can have external references that allow a package to reference an external source of information. The following external references can be used as identifiers:

• Swh: Software Heritage ID
• Gitoid: OmniBOR ID

The following security and package external references are also commonly used as identifiers:

• Swid: Software ID
• Purl: Package URL
• cpe22Type: NIST Common Platform Enumeration version 2.2
• cpe23Type: NIST Common Platform Enumeration version 2.3

Using one or more of these identifiers allows you to correlate a package in SPDX format with vulnerabilities in a vulnerability database. For example, the spdx-2-osv utility takes an SPDX document as input and outputs vulnerabilities found in the OSV database.

SPDX 2.3 also supports external references for known advisories, fixes, and general security information. Appendix K of the SPDX spec contains several examples on how these external references can be used.

SPDX in the near future: 3.0

SPDX 3.0 is a forthcoming major release of the specification intended to expand the number of use cases to include areas like SBOMs for artificial intelligence data and repeatable builds, as well as making the spec easier to read and implement.

To accomplish this, the release will be organized by a broad array of use cases or “profiles” specific to what an individual producer or consumer of SPDX data is interested in. For more information on how profiles are used, please read this blog post.

SPDX 3.0 includes the following profiles:

• Security: Captures security-related information in an SPDX security document
• Build: Includes capturing details of software builds
• AI: Documents a list of software components and dependencies associated with an AI system
• Data: Captures the relevant information about the datasets used in an AI system or application
• Licensing: Includes capturing details relevant to software licensing
• Core: Includes the definitions of classes properties and vocabularies usable by all SPDX profiles
• Software: Extends the core profile specific to software

Looking specifically at the security profile, you’ll find several additional ways to represent security information. Data about a security vulnerability can now be represented in the SPDX document itself. As its own element in SPDX, it can have relationships between itself and one or more packages to describe

• Whether a package has that vulnerability
• Whether there has been an assessment for a particular package/vulnerability combination as to whether the vulnerability is exploitable
• Whether a package has been assessed to be affected by a vulnerability
• Where the information about the vulnerability originates
• Additional references to that vulnerability

For more details on how the security profile works in SPDX 3.0, see the Capturing Software Vulnerability Data in SPDX 3.0 blog post.

SPDX in the future: SPDX 3.1

SPDX 3.1 development is well underway with three additional profiles planned.

• Service: A software-as-a-service profile
• Hardware: Hardware BOM information, especially elements that relate to software
• Safety: Functional safety-related SBOM and hardware BOM information