How to Create a Software Bill of Materials

While there may be days when you feel like spouting “SBOM” from left to right, within the tech realm we’re not talking about another term for a four-letter word that begins with an “S.”

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

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

Let me explain.

Let’s say you need to install Software X to provide specific functionality in your system or 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 to install Software X, you need to install all those other bits as well.

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 also requires libc-ares2, libjs-highlight.js, libnode72, and nodejs-doc. You didn’t count on that. And while you may have checked for the current vulnerabilities found in Node.js, you probably didn’t know to check everything else.

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

To that end, it uses a tool to compile a Software Bill of Materials for each image it uses. 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 that you might find a tool like Syft that will generate more data than you’d like to see, what do you think of that?

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

SBOM standards

Fortunately, standards have been established for SBOMs that provide a common format for describing the composition of installed software (or container images) that makes consuming the reported data much 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. The formats used are RDF, XLS, SPDX, YAML and JSON.
  • CycloneDX – Used for 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 being standards-compliant makes them much easier to use overall.

What is included in the SBOMs?

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

With that said, let’s generate an SBOM with syft and then a list of vulnerabilities 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 administrator privileges):

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

Now run the scan with:

Syft will upload the image and then once the scan is complete it will send everything to the terminal. The information displayed will be something like this:

That’s only a fraction of the output you’ll see and should be pretty simple to understand. The left column is the name of the piece of software, the middle 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 can search each individual package version installed to see if it has any known vulnerabilities. Or, you could go the easy route and use grype, from Anchore.

Generate a Vulnerability Report with grype

SBOM information will give you a lot of detail, but it’s missing one crucial element: vulnerabilities. For that, we will 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 are talking. This is how the above output reads:

  • 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: list of CVE vulnerabilities.
  • 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 to both your security and development teams. For example, as you can see above, the zlib1g package included in the NGINX container has a critical vulnerability. With the CVE listing, you can research it to find out if it’s something that could affect your business. If so, your development team could 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 no matter what tool you use to generate your SBOMs, make sure you understand the output, so you can use it most effectively.

ClusterCreated with Sketch.

Leave a Comment