Software Bill of Materials

Introduction

As a software developer, it’s important to know what dependencies your application is using. This is especially true after the vulnerability we’ve seen in versions 2.0-beta9 to 2.14.1 of Log4J called Log4Shell if you still remember that (CISA, December 2021), (NCSC, December 2021).

That December, a lot of developers needed to search through their own systems and verify that they didn’t use Log4J or the impacted versions for that matter. But, that’s not all there’s to it. You might easily see the versions of the direct dependencies you’re using, but what about transitive dependencies (i.e. the dependencies of your dependencies).

SBOM

In order to know what your dependency tree looks like, you can generate a SBOM for your system. A SBOM, of software bill-of-materials, is a file that describes all your dependencies and transitive dependencies. This allows you to easily see all the dependencies that are (indirectly) used by your system, accompanied by their versions (CISA, nd.), (NCSC, nd.). This last part is important to easily scan if you’re, for example, using a vulnerable version of Log4J.

CycloneDX

Now that we know how we can extract all our dependencies from our system, we need to get a specification so multiple tools can work together for either the generating of the SBOM or the reading of the SBOM.

Luckily, the Open World Wide Application Security Project or OWASP (OWASP, nd.) has our covered. They’ve created a standard called CycloneDX which is a specification used to describe the structure of the SBOM file (OWASP, nd.).

Getting insights

Now that you’ve created your CycloneDX SBOM file, you need to get insights from that SBOM. We know the problem we want to solve, checking if we (indirectly) use a vulnerable package.

There are two routes you can take to get insights into your dependency versions.

1. Check the versions by hand, not continuously
2. Automatically check the versions continuously

For this first route, you can use a tool like It Depends. And for the second route you can use a tool like Dependency Track.

Recommendation

Given the fact that vulnerabilities can be found at any time, I would recommend setting up a tool that continuously scans your SBOM for vulnerabilities. But to be effective, you should generate your SBOM every time you release your application into production. The reason you’d want that, is, so you have insights on the dependency versions that are actually deployed and being used by a real audience.

In the current time and age, I assume you’re already using a pipeline to build and deploy your application into production. In that same pipeline, you’d want to add an extra step to generate a SBOM based on the version that’s going to be deployed. You should then upload this SBOM into your own Dependency Track server and check the results. This has the benefit, that, when a vulnerability is found, your Dependency Track server will notify you that you’re using a vulnerable dependency in production without having to manually check which dependency or which version is vulnerable.

If, however, you don’t have the means to set up your own Dependency Track server, I’d recommend to at least check your dependency versions by hand using something like It Depends and keep an eye the updates of your dependencies or check your counties software security center updates.