What Are Software Bill of Materials Reports?

Understanding SBOMs – Complete Guide for Cybersecurity

SBOMs (Software Bill of Materials) are crucial for understanding and securing the software supply chain by exposing the libraries and dependencies used in applications, enabling better visibility and cybersecurity management. Keep reading to learn why SBOMs are required for a strong cybersecurity strategy.

What are SBOMs, and Why Are They Important?

Software Bill of Materials, or SBOMs, expose software libraries that your developers consume from open-source and third-party packages like compilers and languages. You cannot defend yourself against source code hacks if you don’t know all of the packages that your software consumes. This level of insight into your application dependencies is why Software Bill of Materials are an absolute must for understanding the software supply chain you deliver to your end-users.

SBOMs have finally been recognized as an essential tool for cybersecurity. SBOMs and cybersecurity go hand in hand. In this article, we will review what an SBOM is and why they are required for a strong cybersecurity strategy.

SBOM Format Examples – SPDX and CycloneDX

With the complexities of software, the adoption of SBOMs (software bill of materials) is on the rise. Despite the rise of use, many organizations are still unfamiliar with the current SBOM formats.

What Are SBOM Formats?

SBOM formats are standards that define a unified structure for generating and managing SBOM and sharing them with end users. These formats describe the composition of software in a common format that other tools can understand.

Common Formats

CycloneDX and SPDX are the two popular formats for Software Bill of Materials.

• CycloneDX has a viewpoint of SBOMs from the OWASP world.
• SPDX has a viewpoint originating from a license consumption model.

In terms of SBOM formats, CycloneDX and SPDX achieve the same result. These formats document what is used to create an artifact by digging into obfuscated transient open-source dependencies.

CycloneDX

CycloneDX is a modern standard for SBOM with a viewpoint of SBOMs from the OWASP world. It is a lightweight Software Bill of Materials (SBOM) standard for application security contexts and supply chain component analysis. 

Using CycloneDX, supplier, manufacturer, and target component, tools used to create the BOM, license information for the BOM.

SPDX

SPDX is another SBOM format with a viewpoint originating from a license consumption model. It is an open standard for communicating SBOM information. This information includes components, licenses, copyrights, and security references. It is designed to streamline work and improve compliance by providing a common format to share data.

Differences Between CycloneDX vs. SPDX

How do these two formats stack up? Understanding the difference between these common SBOM formats is important. Here is a breakdown of each format and how they are different.

	CycloneDX	SPDX
Description	CycloneDX is a lightweight SBOM standard for application security contexts and supply chain component analysis.	SPDX is formed with the intent of creating a common data exchange format for information related to software packages for sharing and collection.
Terminology used	package	component
Supported formats	CycloneDX supports XML, JSON, and protocol buffers and get source code on GitHub.	SPDX supports RDFa, .xlsx, .spdx and expands into other formats such as .xml, .json, and .yaml. There’s an online tool and GitHub repository.
Support	supports referencing components, services, and vulnerabilities in other systems and BOMs as well
What it is	BOM Metadata, Components, Coordinates (group, name, version), Package URL, Common Platform Enumeration (CPE), SWID (ISO/IEC 19770-2:2015), Cryptographic hash functions (SHA-1, SHA-2, SHA-3, BLAKE2b, BLAKE3)Extensions: extension points to support future use cases and functionality	SPDX Document Creation Information, package Information, file Information, snippet Information, other licensing information detected, relationships Between SPDX Elements, Annotations
Features	CycloneDX can only be used to track the software components in a project.	SPDX tracks the software components in a product and shares information about the software components with other developers, buyers, and sellers.

Between CycloneDX and SPDX formats, you will recognize an overlap in terminology with a different overall structure in the file formats. See https://cyclonedx.org/specification/overview/ and https://spdx.dev/use/specifications/

These schema definitions equate to a series of tables and relationships between the tables in the RDBM world. The CycloneDX JSON structure and documentation are easier to understand and follow. SPDX goes into much more detail, but the examples are XML snippets. With SPDX, there is no single view of the whole spec represented as a single YAML or JSON file.

Challenges with SBOMs

While SBOMs re critical to our overall DevOps practices, they are imperfect. Here are the top challenges.

1. SBOM data is not consumed or federated.
2. Vulnerabilities of tools
3. Lack of signing of the SBOM
4. Immutability
5. Tracking

1. SBOM Data is Not Consumed or Federated

SBOMs are not useful if the data they generate is not consumed or aggregated up to the organizational level. They become more complex in modern architecture, where hundreds of components are used to create a single application. In this case, an SBOM is generated for each unique component. For this reason, there is no easy way to show a “federated SBOM” of all components used in a single application.

2. Vulnerabilities of Tools

Another issue is the tools to generate SBOMs have vulnerabilities themselves. The vulnerability resides when the tools run, post-build or post-packaging. SBOM generators use files that the compiler or package program creates, such as Rust’s cargo.lock, NPM’s package-lock.json, or an apt-cache.

The gap between the build and SBOM creation provides a hacking opportunity where the SBOM report can be manipulated, resulting in untrue SBOMs.   

3. Lack of Signing of the SBOM

Other challenges include the lack of signing of the SBOM, so we know the provenance in the SBOM report. The signing process is critical for SBOMs and cybersecurity. 

4. Immutability

The biggest challenge is the mutability of the SBOM files. It is important to show history over time without the ability for someone to manually update an SBOM.

Software Bill of Materials files can be edited without any trace, allowing the data to be manipulated. For example, hackers can easily update an NPM package-lock.json prior to your NPM SBOM generation. By doing so, they can disguise any hack in the SBOM. Immutability becomes an issue at all levels of SBOM generation. 

5. Tracking

What was the SBOM generated for, a microservice or an entire application? In traditional development, an SBOM is created at the point in time when the application version’s artifacts are created, giving us an SBOM based on that application version. In microservices, each service is built and deployed independently.

An application is a logical collection of microservices. Application versions are created when an underlying microservice version is updated. So how do we track application-level SBOMs when the application is only a logical representation and never built as a complete unit?

Understanding the Different Levels of SBOMs

Multiple Software Bill of Materials are produced at different levels of the software stack. The following levels are needed to have a complete audit trail of the entire supply chain used to create a single artifact (microservice, binary, library, etc.):

Hardware SBOM

At the lowest level, the supply chain starts at the underlying hardware used, for example, the processor type (amd64 vs arm64). Yes, this level of the stack can also have vulnerabilities. However, this information is not currently gathered by default, even though the SBOM schema can store it. In CycloneDX this data is stored as Components. 

Knowing the hardware used by your build is essential in recreating an artifact. For example, tools in the future may use a ‘consensus build networks’ where all machines must be identical, starting at the lowest level. The hardware SBOM is the way to confirm this level of parity.

Operating System SBOM

The next level of the supply chain is the OS. We need to know the underlying operating system packages installed on the build machine. These operating systems packages affect how the compiler and packagers produce their artifacts and impact the ability to reproduce a build. It could also introduce vulnerabilities from old OS packages still being consumed. OS SBOMs are not currently gathered by default, even though the SBOM schema can store them. In CycloneDX format, this data is stored as Components.

Compilers SBOM

The software compile translates source code into objects. To create a source-to-object parity, we must know what the compiler consumed for input and produced as output. Unfortunately, Software Bill of Materials at this level do not exist outside of commercial build tools such as OpenMake Meister and IBM Rational ClearCase (ClearMake).

Most build scripts that produce a ‘build audit’ report on the files are found in the ‘local’ build directory and not based on what the compiler used. These files are pulled from a source repository (git directory) and listed as the source SBOM. However, the ‘local’ build directory is not the only place where the compiler will find files. If we are to be accurate in our SBOMs we cannot miss files. Software Bill of Material must include all files, even when managed outside your versioning tool. In other words, it must be done at compile/link time to be accurate.  

In the future, compilers must be updated to produce Software Bill of Materials as standard output with the ability to control the inputs and outputs carefully. OpenMake Meister achieved this control using of a Search Path and generated Build Control Files. Another approach is to monitor the file system for reads and writes by the compiler, like ClearMake. The concepts of the GnuMake VPATH, with a ‘first found’ reference is as relevant today as it was 30 years ago. 

Transitive Dependencies SBOM

Transitive dependencies happen when A depends upon B and B depends upon C. C is a transitive dependency to A. SBOM tools will rely on the compiler or packager to output the transitive dependencies, or they will be determined using a recursive lookup. Most Software Bill of Material at this level is accurate and represents where most teams have focused their attention. Transitive Dependency SBOMs are critical as they expose open-source packages.

Packagers SBOM

Packagers, such as NPM, docker build, and dpkg-deb, pull together files and artifacts into an installable package based on a scripted configuration file. They produce two outputs, the package, and the package dependency file. A package dependency file, like package-lock.json or cargo.lock, are example outputs of the packager.   

Some Package SBOMs at this level may contain source code dependencies based on the programming language, packager, and SBOM tools used. Like the compiler SBOMS, the package SBOM may only reference files from the ‘local’ build directory, ignoring all other file locations. 

Application SBOM

Application SBOMs aggregate together all of the lower Software Bill of Materials into a single view. Tools such as DeployHub and Ortelius snapshot all available SBOMs for each artifact in the supply chain. When consumed by an application, the Software Bill of Materials data is aggregated to the logical application level, creating an Application SBOM.

Without this aggregation ability, we lose the application level SBOM.

Tooling to Make Software Bill of Materials Accessible

Tooling makes Software Bill of Materials accessible. While your team may be doing a great job of generating the different levels of SBOMs for each build, we are far from finished. We need the ability to see the information so that it can be used and acted upon by multiple team members. And the SBOM information must have immediate relevance. After all, what good is a microservice’s SBOM if we have no insight into which applications are using the service? 

Maturing in the use of SBOMs will drive the need to aggregate the data and display the information in a way that is easy to read and useful to all. The first step is finding an easy way to associate the generated SBOMs based on the artifact in a simple dashboard view. Unfortunately, we cannot expect everyone to know where the last build was executed and where the SBOM data lies. 

Secondly, in a microservice architecture, we need a method of aggregating SBOM data up to the ‘logical’ application level. This aggregation requires tooling that can define a ‘logical’ application and build relationships between the microservices (or any component) and each ‘logical’ application version

Conclusion: Understanding SBOMs

Understanding SBOMs is key to understanding why they should be an important step in the DevOps process. Both SPDX and Cyclone DX provide what is needed to expose open-source packages delivered to end users. This knowledge is critical when a high-risk vulnerability in open-source is found, and a patch is required immediately.  For additional information on SBOM’s read the report from National Telecommunications and Information Administration (NTIA).