Recently the latest version of the Linux Foundation’s Software Package Data Exchange (SPDX) specification was published. SPDX is a Software Bill of Materials (SBOM), which details a list of all components and licenses in a piece of software. It is one of the key technologies in development to secure the software supply chain.
SPDX, along with CycloneDX, is one of the two major SBOM formats widely used by software vendors and developers. While the SPDX community is hard at work on SPDX 3.0, version 2.x is still getting gradual improvements geared towards solving problems and adding minor features. Let’s take a look at what is new.
Major Changes in SPDX 2.3
A quick context note to better understand the changes in 2.3: An SPDX SBOM is formed of packages interlinked by a series of relationships. Using this simple analogy, SPDX is able to describe a complex piece of software and its dependencies:
Improved Interoperability
As mentioned previously, SPDX is one of the two major SBOM standards along with CycloneDX. The way both standards model software is not the same and converting data between the two is not entirely possible without some loss of fidelity. To make things easier converting between the two, 2.3 introduces some changes to make conversion less lossy.
New Primary Package Purpose Field
SPDX adds a new field to the package data structure called Primary Package Purpose. The idea of this new field is to give a hint to SBOM consumers about how the package should be used. But most importantly, this new field matches the CycloneDX component type, a required field on any CDX SBOM. Before this change, converting back and forth between the standards meant losing this data bit.
Support for new Hashing Algorithms
2.3 adds new hashing algorithms to the list recognized by SPDX: SHA3-256, SHA3-384, SHA3-512, BLAKE2b-256, BLAKE2b-384, BLAKE2b-512, BLAKE3, ADLER32. Again some of these match the list defined in the CycloneDX spec.
New Relationship Types
With this version, SPDX introduces two new relationship types to enrich the links between elements: REQUIREMENT_DESCRIPTION_FOR and SPECIFICATION_FOR. These two join the 43 existing relationship types.
New Time Information Fields in Packages
Packages in SPDX 2.3 have new time fields to express when a package was built and its release date. It also introduces a new ValidUntilDate field which enables document authors to specify an expiration date for the package. Datasets and other time-sensitive components can now express their life span.
Expanded Catalog of External References
SPDX recognizes that software described in an SBOM needs to be referenced to many external sources of additional information about it. This is why in an SBOM, packages can have external references. This is just a fancy name for “other names” that a piece of software may have in other contexts, like vulnerability databases for example. With 2.3, the catalog of external repository identifiers grows in two areas:
Security: One of the main uses of SBOMs today is dependency and vulnerability management. This version introduces advisory, fix, URL and SWID as categories in the security identifiers to link the package to additional security context.
GitBOM: Joining the list of persistent identifiers comes gitoid, the identifier used by the GitBOM project to cryptographically track where a package fits in the dependency tree.
Tools tools tools, get your tools!
Just in time to celebrate the release of SPDX 2.3, the Chainguard SBOM engineering team has been busy updating some of your favorite tools to match the new spec! Here’s a summary of 2.3 improvements:
All of these tools now populate the new package purpose field introduced in 2.3 to give consumers a better hint of what packages are for. If you are a user please try them out and let us know what you think!
