Starting the Security Journey: Producing an SBOM

A hypothetical organization takes the first step on their software supply chain security journey by creating an SBOM for their application.

Michael Lieberman

March 11, 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. This is the first post in a series showing the journey an organization takes from having a single software bill of materials (SBOM) through having a fully-integrated supply chain security platform.

Introducing the Whiskey Tasting Foundation

For this series, we’ll use the Whiskey Tasting Foundation as our example. In reality, this isn’t an actual foundation, it’s just a small web app that I wrote to track my tasting notes. It makes a good example, though, so let’s step into the realm of make-believe. We’ll treat the Whiskey Tasting Foundation as an organization dedicated to giving members maximum enjoyment from their libation of choice. To protect users against being mocked by whiskey snobs, the Foundation wants to make sure the application is secure. They’ve heard that it’s important to have a software bill of materials, so they want to start creating those.

Why have an SBOM?

An SBOM is a comprehensive list of all the components, libraries, and dependencies that make up a software product. It includes information such as version numbers and licenses of each component. In other words: it tells you exactly what’s in a particular piece of software. Why does this matter for security? You can’t secure what you can’t see. Of course, SBOMs don’t solve every security problem, but they provide critical information and a building block for understanding the software ecosystem.

Generating an SBOM

Right now, the Whiskey Tasting Foundation has a single web application, so their needs are not complicated. The application is written in Node.js, which means the Foundation can use the npm-sbom command to generate SBOMs. For single-language applications, language-specific toolings often produce SBOMs that are as good as — and often better than — SBOMs produced by language-agnostic tools.

‍

After cloning the wtf-frontend GitHub repository and checking out the v0.0.1 tag, the Foundation can build an SBOM for version 0.0.1. The following command produces an SBOM in the SPDX format (one of the two most common formats) and saves it to a JSON file named wtf-v0.0.1.json:

npm sbom --sbom-format spdx > wtf-v0.0.1.json

Now what?

If the Whiskey Tasting Foundation were creating an SBOM just as a compliance checkbox exercise, they’d be done. But the Foundation wants to use their SBOM for meaningful security work. So they run the osv-scanner tool against the SBOM to see what vulnerabilities exist in the application:

osv-scanner scan --sbom wtf-v0.0.1.json

‍

Oh no! The application’s dependency graph contains nine known vulnerabilities, including three with a CVSS score in the “High” severity category.