How to Create a Software Bill of Materials

Although there might be days when you feel like dropping “SBOMs” left and right, within the realm of technology we’re not talking about another term for a four-letter word starting with “S.”

SBOM stands for Software Bill of Materials and has become a crucial aspect of security for enterprise businesses and developers. Essentially, an SBOM is a nested inventory of software that comes together to serve a greater whole. SBOMs have become absolutely necessary for maintaining the high standards of security required to do business successfully — especially concerning supply chain risk management.

You see, every piece of software ever created may or may not include vulnerabilities. That’s just a part of dealing with technology. This gets increasingly difficult as a piece of software requires more and more dependencies.

Let me explain.

Say you need to install Software X to serve a specific functionality on either your system or your supply chain. When you go to install Software X, you might find that it depends on Software 1, Software 2, Software 3, and Software 4. So, in order to install Software X, you must also install all of those other bits.

This is always very apparent when installing open source software. For example, when you go to install something like Node.js, you’ll find that it requires libc-ares2, libjs-highlight.js, libnode72, and nodejs-doc as well. You didn’t count on that. And although you might have checked into the current vulnerabilities found in Node.js, you probably didn’t know to check everything else.

This is especially so when dealing with containers. Why? Because you depend on images that you did not create and have no control over. How do you know if the latest NGINX image is free from vulnerabilities? And when you’re building full-stack container deployments, all of a sudden you have to consider multiple images, each of which might contain vulnerabilities.

To that end, you use a tool to collect a Software Bill of Materials for every image you use. One such tool is Syft, which makes it easy to generate an SBOM for the images you use. But how do you read that information? Given you could find a tool like Syft that will generate more data than you care to see, what do you make of it?

Let’s see if we can dig in and add some clarity.

SBOM Standards

Thankfully, there have been standards set for SBOMs that provide a common format for describing the makeup of installed software (or container images) that make consuming the reported data considerably easier.

There are two commonly-used standards for SBOMs:

• Software Product Data Exchange (SPDX) — is an international open standard for listing components, licenses, and copyrights associated with a piece of software. Formats used are RDF, XLS, SPDX, YAML, and JSON.
• CycloneDX — used for use in-application security contexts as well as supply chain component analysis. The formats used are XML and JSON.

SBOMs are used by both security and development teams, so the fact that they adhere to standards makes them generally much easier to use.

What’s Included in SBOMs?

SBOMs display a complete inventory of the application in question, including all open source components, license, version information, and vulnerabilities. The one caveat to this is with tools like syft, they only generate the SBOM, which doesn’t include vulnerabilities. To add vulnerabilities into the mix, you’d have to add a tool like grype.

With that said, let’s generate an SBOM with syft and then a vulnerability list with grype and see what there is to see.

Generate an SBOM with syft

To install syft, open a terminal window and issue the following command (with admin privileges):

Once syft is installed, pull a container image you want to scan, say:

Now, run the scan with:

Syft will load the image and then, once the scan is complete, output everything to the terminal. The information displayed will look something like this:

That is just a fraction of the output you’ll see and it should be fairly simple to understand. The left column is the name of the piece of software, the center column is the version number, and the right column is the package manager used to install the application for the container image.

With this information, you could look up every single package version installed to see if has any known vulnerabilities. Or, you could go the easy route and use grype, from Anchore.

Generate a Vulnerability Report with grype

The SBOM information will give you plenty of details but lacks a very crucial element — vulnerabilities. For that, we’ll install grype with the command:

Now, let’s run a grype scan on the same container image with:

The output of this command will include details such as:

Now, we’re talking. Here’s how to read the above output:

• Column 1 (leftmost) — the name of the installed software package.
• Column 2 — the version number of the installed software package.
• Column 3 — package manager used to install the software.
• Column 4 — CVE vulnerability listing.
• Column 5 — CVE vulnerability rating.

At this point, you not only know every piece of software installed in a container image, but you also know if it contains any known vulnerabilities. That information is absolutely invaluable for both your security and development teams. For example, as you can see above, the included zlib1g package in the NGINX container has a critical vulnerability. With the CVE listing, you can research it to find out if it’s something that might affect your business. If so, your development team could either fix the vulnerability or wait for the official NGINX image to be patched.

Although you might be tempted to overlook syft in favor of grype, both tools have their uses. But regardless of what tool you use to generate your SBOMs, make sure you understand the output, so you can more effectively make use of it.