The Synopsys Software Integrity Group is now Black Duck®. Learn More

close search bar

Sorry, not available in this language yet

close language selection

SBOMs and SPDX: Now and in the future

Gary O’Neall

Oct 27, 2023 / 3 min read

If software is an important part of your business and you need to comply with license terms and protect against security vulnerabilities, you need to know and track what is inside your software. Lists of software components and dependencies are typically referred to as Software Bills of Materials (SBOMs).

Standardizing the format for SBOMs can improve the accuracy and efficiency of managing software license compliance and security vulnerabilities—especially if your software came from a long list of suppliers. This is often the case with software that depends on a commercial library that uses an open source library that in turn includes source material from a different open source project. It’s also becoming the norm for customers to expect their vendors to provide SBOMs, and having a standard in place makes that more efficient for all parties. Further, Executive Order 14028, "Improving the Nation's Cybersecurity,” issued on May 12, 2021, means that the U.S. government will require software suppliers produce SBOMs in a standard format.

Software Package Data Exchange (SPDX) is a standard format for SBOMs (ISO/IEC 5962:2021). Although it has been around for more than 10 years, it has evolved much, perhaps most significantly extending into representing security vulnerabilities. And there is a forthcoming major release that will support several new use cases beyond vulnerability management, such as tracking the build process and data about artificial intelligence models.


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:

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

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

Join us

If any of these topics interest you, please join the SPDX community. We’re an open, collaborative organization and we welcome contributions to help make our software supply chain more secure, reliable, and compliant with licensing and government regulations.

Continue Reading

Explore Topics