What?

Let’s get the terminology cleared up. This post is about:

1. Software Bill of Materials (SBOM) – the idea that you write down what’s inside the software you’re shipping (in a standarised form) so that people can figure out what vulnerabilities might be in there and make risk decisions based on that insight.
2. Supply-chain Levels for Software Artifacts (SLSA) “salsa” – creating attestations from the build process to show that things haven’t been tampered with.
3. Open Source Security Foundation (OpenSSF) Scorecards – a set of checks with accompanying badges and visualisation to show that a range of security practices are being adhered to (showing that you care about security).

None of these things stands alone, they’re all interlinked; and they certainly complement each other – a tripod is more stable than a pole.

SBOM

My earliest memories of the topic of supply chain security come from conversations with Josh Corman a little while after he founded I am the cavalry in 2013. He was taking a sabbatical from Sonotype to work on putting a bill through congress that would mandate SBOMs for stuff bought by the US Federal Government. There were two ideas at the core of this:

1. Nobody would want to sell software with known vulnerabilities to Uncle Sam (because procurement officials would push hard on pricing for stuff with such defects).
2. US government is one of the largest buyers, so if they’re getting SBOMs then for most products the work is done already and everybody else can benefit.

This eventually (in 2021) turned into Executive Order 14028 “Improving the Nation’s Cybersecurity“, and now lies at the heart of work being done by the Cybersecurity & Infrastructure Security Agency (CISA)[1].

Easy level – modern languages

Most modern languages use a package manager that creates a lock file, describing (in detail) the dependencies used by a piece of software. It’s relatively trivial to transpose the contents of that lock file into an SBOM expressed as SPDX or CycloneDX using tools like Syft. This is exactly what I’ve done for a bunch of Dart and Python stuff at Atsign, and I’ve little doubt I’ll be able to follow the same process for Java, Go, Rust and a bunch of other things we use.

Boss level – C

Things aren’t so straightforward with C (or C++). There’s no widely used package manager[2], so there’s no lock file to generate an SBOM from. I’ve been kicking the tyres on a few things that try to integrate with CMake; and logically the compiler and linker should know exactly what’s going in, though maybe not with the correct metadata to generate a good SBOM.

This is of course problematic. C/C++ is the centre of mass for software deployed in production. It’s also ground zero for most vulnerabilities, caused by a lack of memory safety.

SLSA

If SBOM is about the ingredients that go into a piece of software, SLSA is about making sure nobody sneaks anything else in there. The v1.0 spec defines three levels:

Track/Level	Requirements	Focus
Build L1	Provenance showing how the package was built	Mistakes, documentation
Build L2	Signed provenance, generated by a hosted build platform	Tampering after the build
Build L3	Hardened build platform	Tampering during the build

I initially envisaged an implementation process that would start by achieving L1 and progressively step up, but since we were already using GitHub Actions for Continuous Delivery it was pretty straightforward to jump straight to Build L3 (as GitHub provide the hardened build platform). All that’s needed is a little extra effort to get the provenance attestations out, which can be done with the slsa-github-generator action. This takes a bunch of file SHAs from the build process and mangles them into the multiple.intoto.jsonl file that carries provenance details that can then be verified[3].

Scorecard

Sticking with the ingredients/cooking analogy, Scorecard is the kitchen hygiene rating – a measurable way to show that diligent software practices are being used throughout the process.

I’ve written about ‘Implementing OSSF Scorecards Across a GitHub Organisation‘ previously (and spoken at a few conferences on the topic).

Much of the toil generated by getting a good score comes from dependency management, which of course relates to SBOMs. And there’s points on offer for signed releases, which can be measured (amongst other ways) by the presence of a SLSA attestation; so it’s in the Scorecard that the pieces of the supply chain security puzzle really come together to present a coherent picture to people who care about that software.

In some talks I’ve described Scorecard as a way to ‘show that you care about security’, and the various tables and charts that can be generated from a scorecard provide a very visual way to do that.

Bringing it all together

The SBOM can be signed in the SLSA attestation, which contributes to the Scorecard. That’s exactly what I’ve been pulling together for some of the key Atsign repos, and as it’s all open source[4] you can see for yourself how it’s done (and copy/paste into your own work as you see fit).

Notes

[1] Where it’s great to see friends like Allan Friedman keep going with the good work.
[2] People in the know have pointed me at Conan, but it’s early days in figuring out how that might help.
[3] It’s worth noting that GitHub’s Artifact Attestations achieves a similar outcome, and can be used in addition to the SLSA generator. Arguably Artifact Attestations provides much easier verification.
[4] Our OpenSSF Scorecards summary page provides a good entry point.