What is an SBOM? Exploring SBOM Origins and Use in Software Security

SBOMs, or Software Bill of Materials, serve as a window into your software’s individual components, allowing you to make informed decisions about which components to include in your software, ensure your software is free from known vulnerabilities, and prioritize security effectively. 

In this blog post, we'll break down what an SBOM is, where they came from, and how recent legislation has outlined their use in software supply chain security.

‍

Understanding SBOM: Software Bill of Materials

First and foremost, let's decode the acronym: SBOM stands for Software Bill of Materials. At its core, an SBOM is an inventory of the contents of a software package. It lists all the components of the software, including open-source libraries, third-party software, and their versions.

‍

The Origins of SBOMs

SBOMs came about as software began relying on more third-party components and libraries, leading to the need for more transparency into its contents.

The concept of SBOMs gained momentum after events like the Heartbleed vulnerability in OpenSSL, and the more recent log4shell vulnerability. These vulnerabilities and attacks against them had far-reaching consequences, impacting nearly every industry, due to the ubiquitous nature of the underlying components. 

Cyberattacks like heartbleed and log4shell highlighted the importance of rigorous code review, more resources for open-source projects, and the need for thorough security testing to prevent similar vulnerabilities in critical third-party software libraries and applications. 

The SBOM concept, inspired by the manufacturing industry's Bill of Materials, was introduced to more easily address these types of cyberattacks and supply chain breaches. 

‍

SBOMs in Executive Order 14028

In May 2021, White House Executive Order (EO) 14028, titled "Improving the Nation’s Cybersecurity," was issued to address the growing cybersecurity threats to the United States.

According to CISA, key points of the EO included:

1. Removing the barriers to threat information sharing between government and the private sector
2. Modernizing and implementing stronger cybersecurity standards in the federal government
3. Improving software supply chain security
4. Establishing a cyber safety review board
5. Creating standardized playbook for responding to cybersecurity vulnerabilities and incidents
6. Improving investigative and remediation capabilities with cybersecurity event log requirements for federal departments and agencies

According to CISA, part of the executive order’s aim to improve software supply chain security would include requiring developers to maintain greater visibility into their software and make security data publicly available. One of the key recommended ways to achieve this goal was through the use of SBOMs.

‍

Defining the SBOM

Part of the EO directed the NTIA (National Telecommunications and Information Administration) to publish minimum elements for a SBOM within 60 days of the order’s release.

The NTIA’s accompanying guidance provided a set of definitions, minimum standards, and forward-looking projections for SBOMs. 

Their current definition of an SBOM is “a nested inventory for software, a list of ingredients that make up software components.”

NTIA outlines SBOM functionality as being composed of three elements: data fields, automation support, and processes and practices.

Data Fields

The most important element of an SBOM is that it has a clear way of capturing the components that make up software. By using data fields, baseline information about each component in an SBOM can be captured in a uniform way. These data fields provide a way to identify components and track them not only across the software supply chain but also within other beneficial systems such as vulnerability databases.

Automation Support

NTIA identifies automation as being necessary to take advantage of SBOM data, both for integrating SBOMs into your existing vulnerability management practices and for real time auditing of security compliance. 

Practices and Processes

NTIA’s guidance goes beyond stating the structure and data fields for an SBOM. It also outlines the practices and processes recommended when integrating an SBOM into the SDLC (Software Development Lifecycle). 

The recommended processes and practices outlined by the NTIA include:

• Frequency. Whenever new data is known, including when a new build or release happens, an updated SBOM should be issued.
• Depth. An SBOM should contain, at minimum, all top level components and their top level dependencies with enough details to be able to find transitive dependencies.
• Known Unknowns. If the full dependency graph isn’t included in the SBOM, this should be clearly communicated. The author should draw a clear distinction between components where all dependencies are listed and one that contains “known unknowns”.
• Distribution and Delivery. SBOMs should be available in a timely fashion, with appropriate access permissions and roles in place. The SBOM data can accompany each instance of the software, or merely be accessible and directly mappable to the specific version of the software.
• Access Control. If access control is used, the terms must be specified, including specific allowances and accommodations for integrating SBOM data into the user’s security tools.
• Accommodation of Mistakes. SBOM processes are still evolving and they can’t be expected to never contain mistakes. Consumers of SBOMs should be tolerant of the occasional incidental error, as long as it is made in good faith.

SBOM Formats and Standards 

At their core, all SBOMs are composed of the same three elements outlined in the NTIA report, but there are different formats in use.

With the need for automation support outlined in NTIA’s guidance came the necessity of common, machine readable SBOM formats.

NTIA has identified three standard SBOM formats:

• Software Package Data eXchange (SPDX) is an open source project hosted by the Linux Foundation. SPDX is a comprehensive standard that covers a wide range of software metadata and is now an ISO/IEC standard.
• CycloneDX was created in 2017 for use with OWASP Dependency-Track. Designed to solve vulnerability identification, license compliance, and outdated component analysis, Cyclone DX is a more security-focused and lightweight format.
• Software Identification (SWID) tags are XML-based metadata files that provide information about installed software applications. Primarily designed for tracking software on managed devices, SWID tags are an ISO/IEC industry standard used by various commercial software publishers.

Each of these SBOM formats facilitate the sharing of information about software components to NTIA’s standards, though one may be more suitable than another for your industry and use case.

‍

Using SBOMs as Part of Your Software Security Testing

While not currently required outside of federal organizations, SBOMs are an important tool for any organization looking to enhance software security and supply chain security and transparency. SBOMs help organizations make informed decisions about component selection, vulnerability management, and security prioritization. SBOMs can be used in several different ways:

1. Software Security

When a new zero-day attack occurs, teams with up-to-date SBOMs can quickly identify where vulnerable components are in use and focus mitigation and remediation efforts accordingly. 

This marks a significant shift from the industry posture at the time of log4shell, where much time was spent on simply identifying vulnerable software within organizations. Additionally, teams can marry CVE data with SBOM component lists (using protools like VEX) as part of a DevSecOps pipeline. 

2. Patch Management

Because every component in the SBOM is paired with a version number, engineering teams can use SBOMs to quickly identify out-of-date components across the software supply chain and work with suppliers to perform patching or upgrades. 

3. License Compliance. 

The SBOM’s generated list of components allows risk and compliance teams to quickly assess the use of varying open source and commercial licensees within the software supply chain, giving them an accurate picture of compliance with an organization’s license entitlements.

‍

Why Use Mayhem for SBOM Management?

The SBOM isn’t a one-size-fits all tool. One of the weaknesses inherent in SBOMs is that they’re an exhaustive catalog of every component in your applications, regardless of use. To prevent overwhelming teams with noise, and to keep security and patching efforts focused, it’s important to prioritize SBOM components.

Mayhem, a security testing solution built by professional hackers, dynamically profiles applications at runtime and filters down SBOM results to only the components that are present on the attack surface. 

By showing only the parts of the application on the attack surface, false positives and CVEs in unused packages are eliminated from your development team’s remediation list, allowing them to focus on finding and fixing only what’s exploitable.

In addition to making the known vulnerabilities in SBOMs easy to identify, prioritize, and fix, Mayhem goes beyond the scope of SBOM with its guided fuzz testing, which also finds the unknown vulnerabilities—those often behind zero days—making it the ideal security testing solution for comprehensive coverage.

Learn more about Mayhem’s dynamic SBOM and SCA validation feature here.

‍