Software Bill of Materials (SBOM) and the Software Package Data Exchange (SPDX)

allmende
1

grafik

When characterising SBOMs from the perspective of data at first (data-first), there are two main format specifications that inform the discussion around SBOM representations, CycloneDX and SPDX.

As they spring from different ecosystems, eras and learnings, they bring different tooling with them. For the previous reasons of assuming a container-native development environment in #50, we will focus on the cloud-native approach with SPDX here.

Remarks on the SBOM platform choice

An example pipeline in the OWASP example with dashboard is given with:

Licence compatibility tooling is possible with standardised formats and methods. This does not mean that there are other approaches to solving the riddle.

A notable addition is flict, a license compatibility tool. It integrates the OSADL matrix and allows for computational inferrence of the actual compatibility.

Its vendor also offers an integrated container with multiple tools, which is sufficiently up to date.

Programs on the image

For people who feel tempted to learn more about the actual implementations, the go-license-detector has a readme section about the quality of source code license classifiers, and they keep an analysis of documentation practices that lead to detection failure. The Ninka link is broken here, but the project is on GitHub.

This collection of compliance tools could be considered canonical for some use cases. We will have to come up with our own requirements and answers to them later.

Exploring the SPDX ecosystem

The SPDX ecosystem springs around the idea of Handling License Info with SPDX. Conventional practices in the field are combined in FSF’s REUSE initiative that proposes to write one line with a small license header into every source code file.

From an even higher level, license compatibility can be seen as a specific case of licence compliance, esp. in governmental and corporate environments, and REUSE offer a Comparison of license compliance projects. In addition, the SPDX initiative holds a list of Open Source Tools, from validating CLI tools via SPDX generators in various languages to large-scale license auditing platforms for repositories in internal and public source code forges and artifact stores.

Hommage à l'ascendance: OWASP, CycloneDX and DependencyTrack

The SPDX community builds on previous experience in enterprise compliance and license management. This list is not exhaustive, and does not contain (legacy) platforms like ClearlyDefined or FOSSology recommended by REUSE.

Screening SPDX tooling and further resources

SPDX generators

The main work of SPDX generation is automated by CLI tooling that is employed in CI pipelines. These are common projects built on different language platforms. Choosing a compiled language will greatly decrease execution time, as no script interpreter is involved. The effect adds up upon multiple runs, why emphasis on speed is good here.

Visualisation

There are other projects for visualising SPDX data, either in a browser workbench, or as DOT files for graphviz graphs.

SPDX platforms

More integrated management of SPDX for large numbers of repositories is possible with dedicated platforms.

Cloud-native vulnerability scanning, including SPDX SBOM

The whole story around more standardised SBOMs emerged in parallel with discussions on vulnerability scanning in immutable, cloud-native environments. Microsoft lead the way here around SPDX and put a lot of effort in supporting this in the Azure cloud, while the ecosystem eventually catched up. But others like Snyk (commercial) and Aqua Security Trivy (FLOSS) were already concerned with automatic scanning of software artifacts, but with regards to security. It was only natural for them to also acquire the capability to generate SBOMs.

Trivy, the most common FLOSS tool employed in this area, has widespread integration with other platforms, e.g. the container and OCI artifact registry Harbor, as well as CI pipelines.

As we can witness, most cloud-native tooling is written in Go.

Auxiliary resources

Notable findings in the SPDX ecosystem

While technical and corporate in nature, we can extract some practical and theoretical knowledge from the context provided here. First, there is a simple web app that allows to display and analyse the content of SPDX records. Second, we find an exhaustive tutorial by an author of another CC content on the subject of license compatibility, written ten years later. It subsumes many of the discussions around SPDX, and what it is used for. Third we also find a reference to Nix, which has native support for deriving SPDX records from its more sophisticated data model about software.

Web app

The SPDX initiative offers a web application to analyse and modify SPDX documents further.

Tutorial

This piece from 2016 onwards is written by the author of the licence compatibility chart on Wikipedia from 2007 above and very exhaustive, including actual reasoning about license recommendations. It is the most permissive OSI license MIT, our current one, which is preferred there. The AGPL doesn’t find a mention.

Adjacent Nix theory about The Purely Functional Software Deployment Model

grafik

edolstra.github.io/pubs/phd-thesis.pdf at master · edolstra/edolstra.github.io

More on what this means for us and what we can do with that information now in the last part.

2

This is used to verify provenance.

The sops 3.9.0 release notes show how to use this:

Verify artifact provenance

The SLSA provenance of the binaries, packages, and SBOMs can be found within the artifacts associated with this release. It is presented through an in-toto link metadata file named sops-v3.9.0.intoto.jsonl. To verify the provenance of an artifact, you can utilize the slsa-verifier tool:

# Download the metadata file
curl -LO https://github.com/getsops/sops/releases/download/v3.9.0/sops-v3.9.0.intoto.jsonl

# Verify the provenance of the artifact
slsa-verifier verify-artifact <artifact> \
  --provenance-path sops-v3.9.0.intoto.jsonl \
  --source-uri github.com/getsops/sops \
  --source-tag v3.9.0

This example uses:

https://in-toto.io/