What is an SBOM, and why should you Care??

by David Widen, Cole Kennedy | Wednesday, May 12, 2021 | DevSecOps

Developing software is a challenging and often time-consuming task. One of the biggest reasons for this is that creating solutions for novel problems is difficult. In the real world, software engineers will break down complex problems into simpler ones, which allows them to take an iterative approach. Software Engineers accomplish this by using software libraries, and this leads to two major problems:

1. How can you be sure what libraries are used by the software, and

2. How can you tell if those libraries are secure?

To solve this problem, organizations are starting to require an SBOM (Software Bill of Materials) to be delivered alongside application artifacts. In fact, the Biden administration just released a new executive order dealing with this very subject.

What is a Software Bill of Materials? A Software Bill of Materials is a collection of all libraries and components used by the software. This allows IT Operations and Security staff to determine exactly which third-party, COTS, or even open-source software is packaged with your application. Having an SBOM is extremely important when it comes to securing your IT systems and protecting user data.

How to Identify what Ships with your Code

Software is often provided as a binary - this makes it difficult for the average user or IT Operations team member to determine what libraries were included in the code. Things can get even more complex because your software might ship as a Docker image. This means that, in addition to your software's library dependencies, you are also provided platform dependencies (e.g., Linux or Windows packages) that your code requires.

The main issue is, “what software and packages am I actually deploying?” If your software application is comprised of 10 different Java microservices, figuring out exactly what you have running in production can be difficult. In addition to your source code, there are system Java libraries, third-party Java libraries, open-source Java libraries, and perhaps you even pay for closed-source libraries as well.

SBOMs should also include baseline attributes with the ability to uniquely identify individual components in a standard data format. The most efficient generation of SBOMs is as a byproduct of a modern development process. For older software, less-automated methods exist. - ntia.gov/sbom

Keeping track of all of those libraries is a monumental task. Both the Cloud Native Computing Foundation (CNCF) and National Telecommunications and Information Administration (NTIA) recommend that the SBOM be generated during the build process, rather than by inspection.

The SBOM data generated by using the build time data will be more accurate as the build process has visibility of the dependencies used to generate the software. A SBOM generated through scanning isn't likely to capture issues such as the toolchain introducing a bug. SBOMs may also be generated manually. - CNCF - Software Supply Chain Best Practices

The NTIA has released a tool taxonomy with the following categories:

Produce

• Build - SBOM is automatically created as part of building a software artifact and contains information about the build

• Analyze - Analysis of source or binary files will generate the SBOM by inspection of the artifacts and any associated sources

• Edit - A tool to assist a person manually entering or editing SBOM data

Consume

• View - Be able to understand the contents in human readable form (e.g., picture, figures, tables, text, etc.). Use to support decision making & business processes

• Diff - Be able to compare multiple SBOMs and clearly see the differences (e.g., comparing two versions of a piece of software)

• Import - Be able to discover, retrieve, and import an SBOM into your system for further processing and analysis

Transform

• Translate - Change from one file type to another file type while preserving the same information

• Merge - Multiple sources of SBOM and other data can be combined together for analysis and audit purposes

• Tool Support - Support use in other tools by APIs, object models, libraries, transport, or other reference sources

For CycloneDX tools, the CycloneDX Tool Center is a great place to start. For SPDX tools, the SPDX Repository is going to be your starting point. For continuous integration (CI) and signing, check out the in-toto project and our fork. SigStore is a great new project that aims to be the LetsEncrypt of SBOM signing.

How to Determine if you can Trust your Software's dependencies

Knowing all of the different libraries that comprise your software is challenging enough – as an IT Director, your team must also track vulnerabilities and how they impact your software ecosystem. For example, there may be a newly released CVE that affects the Java runtime environment. Your IT team must be able to rapidly determine which Java applications are impacted, and then issue a fix.

Without SBOMs, this is very difficult. In fact, it is effectively impossible. If your organization is unable to capture application dependencies in an SBOM, you are leaving yourself wide open to attack. For example, one of your Java applications might use an open-source library. Unfortunately, that library has a newly published CVE. Without SBOMs, it will take a ton of manual labor to determine which of your software applications are vulnerable.

In addition, the libraries that you use should also have their own SBOMs. For example, an open-source Java library is almost 100% guaranteed to use another Java library – your IT team needs to know what other libraries are being used, so they can track the risk level associated with them. This becomes a problem when your library vendor or the open-source community is unaware of these vulnerabilities, or slow to respond.

The SBOM contains the data security administrators need to understand the risk of software running on their systems in real-time. At BoxBoat we love to automate things. The SBOM provides the data required for automated security controllers, mitigating threats in real-time.

We have been tracking the SBOM requirement over the last year. We have developed open source software to generate signed SBOMs in a GitLab environment and are working closely with the NTIA, DoD, and Linux Foundation to help define standards and requirements with respect to SBOM generation and consumption. Please reach out if you have any questions!