The next step in the security journey: comparing SBOMs

Once you have multiple releases, you have multiple SBOMs. What can you learn from comparing them?

Michael Lieberman

March 13, 2025

Nobody goes from zero to fully-mature software supply chain security in one giant leap. You take smaller steps along the way. After all, security is a journey, not a destination. In the previous post, you saw how the Whiskey Tasting Foundation produced a software bill of materials (SBOM) and used that to identify vulnerabilities in the application. Here’s what happens next.

‍

Releasing a new version

When the Whiskey Tasting Foundation scanned the dependencies of wtf-frontend version 0.0.1, they found nine vulnerabilities, including three with a CVSS score in the “High” severity category. Using npm’s audit function, they were able to quickly update the affected dependencies to versions without known vulnerabilities. They released a new version — 0.0.2 — and created an SBOM for it. Problem solved, right?

‍

Not quite. What was it that actually changed? The Foundation could use `git diff` to find the changes to the package-lock.json file, but that presents a few problems. First, git can be daunting for people who don’t use it regularly. Second, the diff between two versions will likely contain changes beyond the dependencies — code, documentation, GitHub workflows, and so on. Third, the git diff won’t tell you if any of the dependencies changed their license or other meta information. Finally, using git to compare the dependencies requires access to the repository. Let’s say the Whiskey Tasting Foundation wants to raise money by selling its software to private tasting clubs. Those clubs want SBOMs for the versions they receive.

‍

Benefits of comparison

The Whiskey Tasting Foundation clearly needs to create and store multiple SBOMs. But an SBOM sitting on a metaphorical shelf isn’t very useful. Theodore Roosevelt supposedly said “comparison is the thief of joy,” but he didn’t know much about software supply chain security. SBOM comparison is the foundation of understanding changes in your software.

‍

What sort of differences might the Whiskey Tasting Foundation want to understand? The most obvious is changes in dependencies — both direct and transitive. This doesn’t just mean changes in versions, but also changes in the software license used, the project’s home page, etc. SBOM comparisons don’t have to be between different versions of the same software, either.

‍

Basic comparisons

The shell command below can be used to compare the version of dependencies between version 0.0.1 and 0.0.2 of the wtf-frontend. It results in 71 lines of output, though, so it’s a little bit unwieldy. And it doesn't separate updates versus additions and removals, so it requires some extra work to understand the types of changes.

‍

diff -y --suppress-common-lines \

<(jq '.packages[] | .name + " " + .versionInfo' wtf-v0.0.1.json | sort) \

<(jq '.packages[] | .name + " " + .versionInfo' wtf-v0.0.2.json | sort)

‍

For a first pass, this is manageable. If the Whiskey Tasting Foundation replaces the “versionInfo” with “declaredLicense” above, they can see license changes in the dependencies. In this particular case, no packages changed license, but some packages were added or removed, so it still gives output. It’s cumbersome, but functional.

‍

Imagine the Whiskey Tasting Foundation introduces a backend software package or mobile applications. Now they want to compare SBOMs between those projects to see which dependencies they have in common. This makes the “simple” shell command above even harder to work with. There has to be a better way, right? The next post in this series will show how the Whiskey Tasting Foundation can use GUAC to view their entire application portfolio.

‍

Like what you read? Share it with others.