Software Bill of Materials(SBOM) 101

These days, Software Bill of Materials or SBOM has turned into a buzzword and it is possible to see something related to SBOM in almost every AppSec-oriented application.

However, there is still confusion about what SBOM really is, why we need it and how to create one.

This article will try to shed some light on SBOM and will present you with a use case regarding the Spring4Shell vulnerability. Okay if you are ready let’s get started.

What Is SBOM?

SBOM is a list of components found in an application along with the hierarchical relations between these components. In a manner, it’s like the ingredients list of a Twinkie package.

Instead of seeing some sugar or carbohydrate values on it you will be seeing a structured list of components, libraries and modules that are used to build a given software.

Why Is It Useful?

Keeping a list of ingredients means enhancing the supply chain integrity of your applications and having crucial information at the disposal of security, development and compliance teams at all times.

With the average number of components in an application surpassing 500 and new applications being built each day, it is a good idea to stop procrastinating and start working on SBOM today.

When you hear about that new vulnerability discovered in a component that you know you are using, the last thing you want is to spend hours trying to find out which applications actually use that component actively. SBOM brings visibility into your applications and helps you decide if you are at risk in hours instead of weeks with a simple text search.

Another case is when the compliance team assesses license risks associated with the open source components. You might be using a component with a license that requires you to open source your software as well or make a payment to the developer of the component.

Without having an inventory of those components, having to look into hundreds if not thousands of components to see if you comply with the relevant license restrictions can be a nightmare.

On the other hand, federal government regulations (especially Executive Order 14028 in the US) have started to mandate suppliers to provide SBOM to be able to sell their solutions to the federal government. With a domino effect, the private sector is expected to follow suit in the near future and start to ask for SBOM from suppliers.

License risks have been a popular topic in M&A conversations as well and buyers are now more sensitive to risks that come with the acquired software. To prevent open source components from undermining or prolonging a deal, there has also been an increased awareness on the sellers’ side.

Therefore, having a structured way of maintaining SBOM is a good idea not only from a technical perspective but also from a business perspective as a sales or even acquisition enabler.

How To Generate An SBOM?

There are multiple ways of generating an SBOM. Developers can generate an SBOM during the build stage of their CI/CD pipelines.

For this you will need a plugin or a programming language specific SBOM generation tool.

Secondly, you can use an SCA tool. Usually, SCA tools will try to analyze your application’s dependencies and generate an SBOM file which will check for vulnerabilities and open source license violations.

Lastly, it may be possible to generate an SBOM from a docker container. In the modern “containerized” software development world some tools can generate or partially generate a desired SBOM file.

Example: Detecting Spring4Shell Before The SCA Tools

Since we have all the inventory of the application thanks to SBOM, it’s possible to use that information to detect if we have vulnerable systems even before the vulnerability database of our SCA tool is updated or before an SCA scan is kicked off in the pipeline.

In this article, Syft will be used. Syft is a CLI tool and library for generating a Software Bill of Materials(SBOM) from container images and filesystems.

Let’s dive in, it’s really easy to use.

Of course first and foremost Syft should be downloaded and installed with the following command:

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

That’s it! Syft has been installed. The next step will be creating the SBOM of the preferred project and exporting its output in “cyclonedx-json” format which is the supported format by Kondukto.

syft {project_directory} -o cyclonedx-json > sbom.json

You may import SBOM to Kondukto in two ways:

1. Via GUI
2. Via Kondukto CLI(KDT)

In this example, we will go with KDT:

kdt sbom import -f {results_file.json} -p {project_name} -b {branch_name}

As you can see from the above screenshot the SBOM file was imported successfully. We can validate it via Kondukto UI SBOM page:

Creating a basic filter to grab spring-web@5.3.15 versions you just have to write it to the filter section! After that you’ll be able to see instantly which of your projects have used the vulnerable module and you can immediately proceed to the patching phase.

You can find out the part II of this blog “How To Generate and Audit SBOM In a CI/CD Pipeline” in this link.