By Phil Odence
Software Package Data Exchange® (SPDX®) is a standard format for describing a software bill of materials that supports a range of use cases, not least SBOMs to manage security vulnerabilities.
SPDX has been an open project under the auspices of the Linux Foundation for over a decade, all the time with the purpose of describing software content. More recently, SPDX became an ISO standard. (https://www.iso.org/standard/81870.html) Well ahead of its time, SPDX was initially designed with an eye toward license compliance but has also become a standard for supporting security use cases as recognized by the Cybersecurity and Infrastructure Security Agency (CISA).
Arguably, the most complex use case is including license and copyright information about software packages. This is because legal ownership can apply to the package, files within, and even a small collection of lines of code. To fully support such usage, that standard needs to be able to handle the granularity, which is also needed for some security use cases. Additionally, legal analysis requires a standard, immutable list of licenses, their text, and ways to express complex licensing situations. So, SPDX includes a collection of licenses (also adopted by other projects) and a license expression language.
From early in the days of the project, there was interest from some corners in a lighter version that was more straightforward, allowing companies to get started providing package license information in a standard format. The standard evolved to specify a core set of required fields and a superset range of optional fields. This concept laid the foundation for “profiles” currently being defined, different sets of optional and required fields required for a given use case. Another key dimension of SPDX’s evolution was adding relationships and references to external documents. This was originally developed with the idea of linking different SPDX docs to allow, for example, the structure of an SPDX description to mirror the structure of the software it describes. The core capability, though, allows for linking to other types of documents and is critical for support linking and SBOM to associated security information.
The recent ramp in interest in SBOMs has been focused on the security use case, driven by the general climate of cybersecurity risk and, more specifically, by the US government’s intent to require SBOMs of vendors. SPDX has been moving in this direction for some time, and the specification includes the functionality to support it. In 2016, version SPDX released version 2.1, which included specific external reference fields for the security use cases. The current 2.3 version was specifically aimed at increasing security support, and a key profile planned for the 3.0 release targets this use case.
SPDX utilizes the external reference capability of SPDX and adds new reference categories to support linking to security documents. The spec’s Annex K: How To Use SPDX in Different Scenarios https://spdx.github.io/spdx-spec/v2.3/how-to-use/ goes into detail and provides examples of how to link to various vulnerability-related resources, including CPEs, CVEs, VEX information including CSAF-formatted security information, code fixes, and other information. There is also a section mapping the NTIA minimum elements to the corresponding fields in SPDX.
SPDX 3.0, currently under active development, extends the concept of profiles introduced in 2.2 and has one specifically designed for security. With 3.0, SPDX documents will embed more context for the linked security data, allowing tool efficiency.
Profiles are sets of required and optional fields for a specific use case. So whether a document conforms to the spec will be relative to a use case. For example, a security-oriented SBOM may not have the features required to comply with the legal profile but on the other hand, could have all the required fields to comply with both. A core profile will include a minimal set of elements to describe a software package, corresponding roughly to what has previously been referred to as SPDX Lite. Beyond that, then, will be several profiles, including Security, Legal, and others, such as one for AI apps or one that includes build information.
One important external reference will be to CISA Vulnerability Exploitability eXchange docs, an envisioned machine-readable, vendor-supplied assessment of vulnerabilities in their software. VEX is still a bit of a moving target, and multiple “flavors” seem to be arising without a standard having been nailed down. In any case, SPDX 3.0 will support it. Additionally, based on input from various open source projects, the group is considering incorporating a simple set of minimal security elements as optional SPDX fields in the Security profile. This would not be a new alternative to CSAF or VEX but rather a lightweight way for projects, not set up to go deep, to provide the basic security info common to all vulnerability description formats.
A challenge remains for anyone exchanging SBOMs (in any format) concerning unambiguously referencing software elements. One SBOM’s “Log4j” is another’s “Apache Log4j.” It’s a similar issue to the one SPDX solved for license references. A loose analogy: If airlines were to share flight schedules without agreeing on how to refer to London Heathrow, they’d be useless. This can’t be solved locally to SPDX, as it’s needed for other formats and applications. The group believes there may be a solution in the combination of Package URL (PURL) for components associated with package managers and CPEs and SWID for commercial software components. Support for OmniBOR (Universal Bill Of Receipts) has also been added to SPDX 2.3, another possible solution to uniquely identifying software components.
SPDX has demonstrated a solid foundation and the ability to evolve to meet users’ evolving needs. The introduction of profiles allows for considerable flexibility. Recently a constituency has started up a functional safety (FuSa) profile. The subject of hardware has come up for discussion as well, and the spec may one day be referred to as System Package Data Exchange… SPDX.
SPDX Myths
SPDX can’t support security.
False. SPDX currently supports linking to security information, and that capability will be extended for a broader range of use cases in the future.
SPDX is old and complicated.
Partially True. The team would say “well-established.” “Complex” might be a better word than “complicated,” and so is the set of problems it addresses. And with optional fields, SPDX Lite and profiles, it can be as simple as it needs to be and still address the problem. The architects of SPDX have taken the long view to build the flexibility to handle an uncertain future.
SPDX is not human-readable
Partially True. SPDX supports various formats, including a very human-readable spreadsheet for simple examples. It gets most challenging with XML and JSON, which depends on the human. But the reality is to describe software of any size and do anything useful with the information, machines need to be involved, and human eyes would only slow the process.
SPDX doesn’t support VEX.
Mostly false. Today SPDX documents can make external reference to VEX and VDR documents. We are in the camp of people who believe that is the best way to support VEX. Because SBOMs and knowledge about the vulnerabilities in contained components move a very different pace, we don’t think it makes sense to expect that information is always included in the SBOM document.
SPDX is only for license compliance.
False. OK, it depends on when the statement was made. Ten years ago… True.
SPDX is not a format for describing SBOMs.
False. It is.
SPDX cannot describe hardware BOMs.
True… today. The format is flexible enough to evolve in this direction in the future, and it is currently being explored.
