By Jeff Schutt, Gary O’Neall, and the SPDX Security Profile team

The flexibility of SPDX 3.0 allows users to either link SBOMs to external security vulnerability data or to embed security vulnerability information in the SPDX 3.0 data format, thanks to support for a security-specific profile. This is different from SPDX version 2, which enabled users to link an SBOM to vulnerability-related information. The concept of profiles (Software, Security, License, etc.) is used in SPDX 3.0 to express various types of metadata in logical and semantically meaningful groupings. See the Understanding SPDX Profiles blog post for more information on how profiles are used in version 3. 

Static SBOM Data vs. Dynamic Vulnerability Data

SBOMs capture static information about a specific version of software at a specific step in the software development process (for example, build time).  Unless there was an error in the SBOM, this information does not change.

Vulnerability data, on the other hand, is more dynamic.  Consider that vulnerabilities are typically discovered after a software version is released and investigations provide additional context into the impact of the vulnerability on a specific instantiation of the software package. For example, during the vulnerability investigation and disclosure process a coordinator may issue a CVSS vectorString, baseScore, and baseSeverity. A software producer may then change these CVSS values based on Temporal, Environmental, Threat, or Supplemental metrics. Using the Exploit Prediction Scoring System (EPSS), the “probability [0-1] of exploitation in the wild in the next 30 days (following score publication)” will change over time [1]. And at any point in time the vulnerability may be listed as known to be exploited, confirming the risky nature of the specific vulnerability. How does a software producer or consumer track this information over time?

Organizations that desire to use SBOMs as part of their vulnerability management lifecycle may consider the following steps::

• An SBOM is produced for the package at build time that lists direct and indirect dependencies
• A vulnerability is discovered in one of the dependencies after the software and SBOM are released
• The vulnerability is investigated to see if the vulnerability can be exploited in the package containing the dependency
• If affected, a patch or new version of the dependency is integrated into the software
• A new release of the package and a new SBOM are created
• If the vulnerability is not exploitable, a description as to why it is not exploitable is provided

SPDX 2.3: Linking Vulnerability Data

SPDX has supported vulnerability data since release 2.1 in the externalReference property on packages.  This field allows the SBOM to accurately reference persistent identifiers and security vulnerability data in a variety of formats. Package URLs, supported since release 2.2, can be used to correlate packages with vulnerabilities. Security Advisory, Fix, URL, and gitoid related data was added in release 2.3. Information about how to use the externalReference property in different scenarios are documented in Annex K of the specification.

One issue we discovered in SPDX 2.3 is that any changes to the vulnerability data required modifying the SPDX Package itself.  This is done through creating a new SPDX document which “amends” the previous document – not the most convenient method when vulnerability data may change more frequently than the static package metadata. This is resolved in SPDX 3.0 where the Security Profile allows users to track vulnerability information separately from software component information contained in the Software Profile. 

SPDX 3.0: Embedding Vulnerability Data

Within SPDX 3.0, there are two types of security Elements:

• Vulnerability Elements provide a description of the vulnerability
• Assessment Relationships provide an analysis of how the vulnerability relates to a software artifact

This separation enables a list of vulnerabilities to be expressed independent of their relationship to software. It also enables a user to create relationships between one SPDX 3.0 Vulnerability Element and many SPDX 3.0 Software Artifact Elements or between many Vulnerability Elements and one Software Artifact Element. 

SPDX 3.0 Relationship Elements are used to assess the changing status of a vulnerability with respect to applicable software–including assessments of the vulnerability against both software products as top-level-SBOM-components and subcomponents such as SPDX File, Snippet, and/or Package Elements. New relationships can be created to account for the dynamic and short shelf-life of some vulnerability data, enabling SPDX 3.0 vulnerability metadata to be updated at a quicker cadence than the SBOM.

SPDX 3.0 has been designed in support of existing standards and frameworks including CVE, ISO/IEC 29147:2018, ISO/IEC 30111:2019, OASIS CSAF, FIRST CVSS, FIRST EPSS, CISA SSVC, CISA KEV, and VEX. The ability to track vulnerability-specific metadata as it relates to SPDX 3.0 Software Artifacts provides richer context and enables vulnerability metadata that is already maintained by some organizations to be more easily passed from software producer to consumer. For example, SPDX 3.0 supports many Assessment Relationships related to a single vulnerability. These vulnerability assessments may be performed by the open source project, by the developer who integrated that open source library, and by the software security or package distribution team. This additional security context improves risk management throughout the software supply chain, from upstream projects to downstream projects, from open source projects to commercial and proprietary software producers, and from projects or producers to software consumers. 

SPDX 3.0 supports the minimum data fields defined in CVSS, EPSS, KEV, SSVC, and VEX. This traceability of vulnerability metadata throughout the software supply chain, enables a software producer to have more accurate vulnerability information from their upstream components’ owners, and provides flexibility if any organization in the supply chain wants to translate from another vulnerability-specific metadata format into SPDX or vice-versa.  For example, this can be advantageous to an organization that may want to reuse the information coming from the SPDX 3.0 Security Profile in their CSAF-formatted security advisories. 

In conclusion, SPDX 3.0 enables users to track incremental security vulnerability information, improving the utility of SBOMs without having to re-publish or invalidate prior SBOM data.  This allows for updates to the SBOM to align with software release cycles while enabling independent and much more frequent security updates to document corresponding vulnerabilities and assess how they relate to SBOM components. SPDX 3.0 enables a multitude of vulnerability management use cases throughout the software supply chain. Does it support your intended use? We welcome your feedback and contributions whether that’s by joining our meetings or opening an issue or pull request in the specification repo.

Stay tuned for a subsequent blog walking through two examples of capturing vulnerability data respectively in versions 2.3 and 3.0.