Advancing SBOM standards: Snyk and SPDX

Many people will have heard of the SPDX project through the work on the SPDX License List. This list of canonical identifiers for various software licenses is used in a huge range of developer-focused software, from Snyk to GitHub. But the SPDX project, which is part of the Linux Foundation, has a much broader focus on providing an open standard for communicating software bill of material information.

A software bill of materials, or SBOM, is a list of the components in a given piece of software. A common analogy is the list of ingredients on food packaging. Software is becoming increasingly complex, and increasingly composed of more and more components. That doesn’t just mean open source libraries and frameworks; a modern software application may consist of multiple services each with their own SBOM, packaged together with tooling that might bring in yet more dependencies.

SPDX aims to standardise how we define that SBOM, and provide a machine readable format that the wider software industry can build tooling around to solve myriad supply chain problems.

This is increasingly helpful in solving today’s software security challenges. Just last month U.S. President Biden issued an executive order regarding Improving the Nation’s Cybersecurity, which explicitly mentions the adoption of SBOMs and the formalisation of SBOM standards as a goal. You can read about our thoughts about the executive order in more detail in our software supply chain security requirements blog.

Snyk and SBOMs

The manifest files used by package managers do contain lists of software, but they’re generally not regarded as SBOMs. They’re more narrowly focused on a specific use case, containing just enough information needed to install the listed software.

Snyk integrates with a wide range of different package managers and developer tools to help identify vulnerabilities in the software components used. In doing that we need to build up a SBOM under the hood, normalising the list of software and augmenting that list with additional metadata from other sources. The Snyk tooling mainly focuses on presenting that information alongside information about vulnerabilities, but Snyk customers can access that raw SBOM via our built-in reporting or powerful API.

In fact, you can think of Snyk client tools like the CLI and CI/CD plugins as generating an SBOM, while Snyk’s backend takes an SBOM and returns vulnerability data, or provides automation around that data to help you fix issues. It’s this extensive experience that leads to our interest in emerging standards in this space.

Snyk and SPDX

Although SPDX as an SBOM standard has been around for several years, the recent work on the v3.0 draft specification has much promise. We’ve been looking closely at the draft proposal for a vulnerability profile for SPDX, which allows for adding vulnerability data (sometimes referred to in SBOM circles as VEX, or vulnerability exploitability) alongside the information about software components.

As part of helping to validate the work on the specification, we built a simple tool called snyk2spdx. snyk2spdx serves a singular purpose; it consumes the underlying Snyk test data (which includes the SBOM information) and outputs it to SPDX v3.0, including the vulnerability profile. Here you can see the simple output.

1$ snyk test --json | npx snyk2spdx | jq
2{
3  "id": "SPDXRef-todo-list",
4  "name": "todo-list",
5  "specVersion": "SPDX-3.0",
6  "profile": [
7    "base",
8    "vulnerabilities"
9  ],
10  "dataLicense": "CC0-1.0",
11  "creator": "Organization: Snyk Ltd",
12  "documentNamespace": "spdx.org/spdxdocs/todo-list-2bd968c5-d497-41ec-83d7-5ee652720c53",
13  "description": "Snyk test result for project todo-list in SPDX SBOM format",
14  "created": "2021-05-05T16:20:28Z",
15  "vulnerabilities": [
16

This is just the header, here’s a link to the full SBOM output for those particularly interested in the format.

We built this tool to help us experiment, and to provide feedback on the current draft specification. SPDX v3.0 is still a moving target, and doesn’t yet have widespread tool support or published schemas. These things will undoubtedly come in time, and as they do we’ll likely move this sort of functionality into the core Snyk CLI, and expose and consume SPDX in other parts of Snyk too.

If you’re interested in SBOMs in general and VEX in particular, snyk2spdx can help you start experimenting. Maybe you’ll even choose to start contributing to the work on the specification or to the larger effort of evangelizing and building software around it.

The future

As SPDX gains broader attention, Snyk is working closely with the Linux Foundation to improve the standard and expand the ecosystem of tools. This recent Linux Foundation blog post summarizes why and how the open source community identified the need to address the challenge of SBOM over a decade ago.

Standards at the right time and the right place have the potential to move industries forward. The Biden Executive Order is clear that SBOMs have a key role to play in helping to address wider software supply chain security. At Snyk, we look forward to continuing to contribute to efforts in this space.