Explaining Software Bill of Materials (SBOM)

What is an SBOM or Software Bill of Materials, and why is it important to be aware of it?

Before constructing or manufacturing anything, a list of all the required components, their quantities, sub-components, etc., is required to get an estimate of costs, the quality of components, and many other things. This list is called the Bill of Materials or BOM.

BOM is part of every industry: production, electronics, construction, and every other field. When a bill of materials is made with respect to the information technology industry, it’s called a software bill of materials or SBOM. Also known as a software supply chain, SBOM helps determine what all open source and third-party libraries are being leveraged in the project.

What is SBOM?

Put this is the SBOM meaning: it is a document or list containing all the known components, libraries, third-party software, etc. These constituents are known as dependencies, and these dependencies, in turn, create the software supply chain: the interlinked network of all the dependencies, software information, activities, and processes that lead to the creating of a software artifact.

Why do you need SBOM?

This helps companies estimate costs before building anything and ensure that components of the highest quality and efficiency are used. When dealing with buyers and other vendors, having an SBOM allows you to demonstrate the inner layers of your product as an SBOM is usually requested by anyone interested in buying the product.

Using SBOMs to manage assets

There is a popular statement in the security industry that goes

“You can’t protect what you don’t know”,

which points toward a lack of a proper system that allows you to track your asset and inventory efficiently so that you know which dependencies, libraries, etc are being used by your products at all times.

One popular example of this is when the Log4j 0-day happened in December 2021, most organizations didn’t even know they were being exploited and attacked because they were unaware that Log4j was being utilized by their applications as it was a dependency buried deep in their technical stack.

An SBOM solves exactly the problem we mentioned above. You can map the attack surface by keeping track of every dependency involved in the project. Protecting a known attack surface is relatively easier than protecting assets you are unaware of.

How to use SBOMs to analyze supply chain vulnerabilities

A supply chain (or an SBOM) can also be looked at as a waterfall pyramid of all the dependencies of your project, followed by the dependencies for the first layer, and so on. If a vulnerability exists deep inside this supply chain, everything that utilizes the poisoned dependency will become vulnerable. Supply chain attacks have increased by 600% over the last few years. The far-reaching and widespread consequences that supply chain attacks pose in the industry are exactly why an SBOM is crucial before developing or purchasing any product.

Let’s take a look at two prominent supply chain attacks that we have seen in recent times.

SolarWinds hack

We all know the havoc that the SolarWinds breach caused as the year 2020 ended. The SolarWinds Orion hack was one of the biggest cybersecurity incidents of the 21st century, a supply chain attack that affected more than 18,000 organizations, including the US government.

Hackers known as Nobelium gained unauthorized access to SolarWinds code repositories in late 2019 and, without raising any alarms, could inject malicious code into the SolarWinds Orion monitoring package successfully. SolarWinds, unaware, kept pushing update packages with malicious code for quite some time, allowing hackers access to multiple vendors down the supply chain.

Dependency confusion in packages

This category of supply chain attack came into the news in early 2021 when a bug bounty hunter used malicious packages in popular repositories like npm, PyPi, and RubyGems to breach more than 30 organizations.

During their research, they found that if packages with the same name as private packages are uploaded to public repositories, the code defaults to downloading the malicious packages, resulting in code execution deep inside corporate networks.

We know about a vendor that found SolarWinds-related IOCs 3 months before the big hack happened and they removed everything associated with SolarWinds. This made them safe from the huge breaches that other organizations faced. This was possible because they had an SBOM of their product, knowing straightway how SolarWinds was a dependency and how to mitigate the issue.

Standards and frameworks for SBOMs

SBOMs are still being managed through a simple Excel sheet or a spreadsheet of one or another kind. This has obvious associated risks with it: lack of data integrity, no version control, possible data loss, and multitudes of issue that comes with using the spreadsheets as *cough* databases *cough*.

To tackle this, Software Package Data Exchange or SPDX is developed. SPDX is an open standard for SBOMs, leading to efficient management and even automation of SBOMs and their usage by other tools, e.g. CI/CD pipelines.

SPDX ensures that SBOM data is enriched with metadata related to security, licenses, compliance, etc. This is a crucial step taken in order to improve supply chain management and make it more secure.

Similarly, the National Telecommunications and Information Administration or NTIA has published “The Minimums Elements for an SBOM”. This document provides a guideline on what should be included in an SBOM. This is built around defining the basic usage of SBOM, whether it is vulnerability management or managing licenses and inventory. NTIA has defined baseline details like the supplier name, vendor name, component name, version, etc. This ensures comprehensive coverage, which is important when SBOMs are looked at from a cybersecurity perspective.

Best SBOM Tools

To facilitate the process of creation and usage of SBOMs, below are some of the tools that can prove to be crucial:

Syft

A CLI tool, Syft, is written in Go. It scans through your container images and filesystems to discover packages and libraries using which SBOMs can be built.

With a wide support for containers, whether it is Docker or OCI, Syft can export your SBOMs in whichever format you’d like: CycloneDX, SPDX or others.

Syft lets you build SBOMs based on packages present in container images or filesystems.
Not only this, it allows multiple features:

Hexway ASOC

A single solution for all your DevSecOps needs, Hexway ASOC helps you simplify your vulnerability management. With CI/CD integration, it can be integrated into your automation workflows and SDLC lifecycle, providing a secure environment.

SPDX

As we mentioned, SPDX is the open standard for SBOM and the team behind SPDX also provides their own tools that can help you with SPDX documents:

Validation of numerous SPDX documents you work with
Conversion of SPDX documents into other formats to make them compatible with different tools
Comparison of multiple SPDX documents to understand the differences in components, vendors, etc.
Transformation and customization of existing or new SPDX documents as per business needs.

Tools range from open source to online and are also commercially available.

OWASP Dependency-Track

The apex web security organization OWASP has its tool for supply chain security called OWASP Dependency-Track. It leverages the data inside SBOMs and scans dependencies and packages for known vulnerabilities, resulting in lower risk and better supply chain vulnerability management.

Dependency-Track allows you to customize vulnerability sources and feeds with customizable alerts. If anything malicious is seen, you’ll be notified. It also offers extensive integration for DevSecOps tools like DefectDojo, Fortinet SSC, Jira, etc.

As the threat of supply chain security looms, SBOMs are the one thing that can single-handedly improve the robustness of your supply chain security program. SBOMs help with things like compliance, licensing, mitigation of risk, change, supply chain management, and numerous other things to help any organization keep its supplies and dependencies free of vulnerabilities.