What is an SBOM and How is it Different from a CBOM?

In May 2021, President Joe Biden signed an executive order (EO) aiming to strengthen America’s cybersecurity. One key point in the EO was the need to improve software supply chain security, and reduce the vulnerabilities that allow adversaries to launch cyberattacks against public and private organizations.

In June 2021, the National Telecommunications and Information Administration (NTIA) published more specific requirements of the Biden Administration’s EO. One important item: vendors must maintain a software bill of materials (SBOM) for all software sold to the federal government. This mandate is an important step towards advancing transparency in the software supply chain and addressing the increasingly serious problem of supply chain attacks.

An SBOM is a catalog of all the software components (including open source components) in the codebase, as well as component versions, patch status, and licenses. Any organization purchasing a third-party software can benefit from asking the vendor for a SBOM.

Discussions about SBOMs have taken off since the Biden Administration EO. Another phrase, however, had already been introduced in 2018: the Cybersecurity Bill of Materials (CBOM). The CBOM is a document that brings both a software and a hardware bill of materials under one umbrella.

What is an SBOM?

An SBOM is a list of the components in a software application. It also catalogs the versions, upgrades, known vulnerabilities, and dependencies in the components. The SBOM document can be embedded with each application, and provided to compliance auditors for more reliable audit requests.

Almost all software contains a mix of custom-built code, commercial off-the-shelf code, plus open source components (which comprise 70 percent of codebases). Software vendors that leverage such a mix during software development must maintain an SBOM for their codebases.

What Does an SBOM Contain?

Open Source Components

An estimated 99 percent of modern commercial codebases contain at least one open source component. These components allow developers to shorten development time, and accelerate time-to-delivery and time-to-market. Few companies, however, have full visibility into the open source components that comprise their software packages. A comprehensive SBOM lists these components to provide better visibility into open source exposure.

Open Source Licenses

Businesses that fail to comply with open source licenses are vulnerable to legal risks, and the risk of intellectual property (IP) compromise. An SBOM lists the licenses that govern the components so vendors can properly assess their legal and IP risk and assure that their codebase doesn’t contain any license conflicts.

Open Source Versions

Roughly 91 percent of codebases contain components that are more than four years out of date, or haven’t seen development activity in years. When components are not maintained, patched or improved, existing security vulnerabilities go unaddressed. An SBOM lists the versions of all open source components, so that vendors can determine whether they’re using outdated code and putting their customers at risk of cyberattacks.

Open Source Vulnerabilities

From 2019 to 2020 — that is, just one year — the number of codebases containing open source components with known security vulnerabilities increased from 60 to 75 percent. Vulnerabilities in open source software have led to several high-profile security breaches, including the Equifax breach of 2017. By maintaining an SBOM, software vendors can keep track of any open vulnerabilities and take action to address them.

Benefits of an SBOM

Better Visibility for Software Vendors

A SBOM provides clarity into what actually constitutes a software product. This includes open source components, versions, licenses, as well as critical metadata such as:

• Origin
• Maintainers
• Digital signatures and hashes of:
  • Executable software
  • Data files
  • Configuration files

The SBOM is also a continuously updated catalog of known vulnerabilities in the components. If a vulnerability is not found, it cannot be patched. That increases the risk of data breaches and supply chain attacks. By increasing visibility into vulnerabilities and dependencies, the SBOM enables software providers and their customers to keep bad actors at bay.

Increased Transparency for Software Buyers

With an SBOM, software buyers will know what they’re purchasing. Plus, an understanding of known vulnerabilities will help buyers prioritize their security needs. If they need to make new security investments or security tradeoffs based on their risk management program, the SBOM can provide the visibility they need to make the best possible decisions.

Reduced Risk of Supply Chain Attacks and Data Breaches

To prevent cyberattacks or data hacks, it’s essential to know the third-party binary and open source code and security vulnerabilities in the entire software supply chain. A SBOM provides a list of these vulnerabilities so vendors and their customers can take action to reduce their risk. They can also perform license compliance checks and quality assurance checks to determine software health.

Drive Market Innovation

With an SBOM, software vendors can earn their customers’ trust and demonstrate the potential ROI of their software products. If their products are secure-by-design, vendors can compete more effectively and command higher prices. Competitiveness will drive future innovation in the software market, and generate powerful outcomes for both buyers and sellers.

How to Create an SBOM

The most optimal way to create a software bill of materials is to use a Software Composition Analysis (SCA) tool.

SCA tools can inventory all open source and third-party components in the software’s codebase, and generate a complete SBOM that can track and update:

• Third-party and open source components
• Commercial/open source licenses
• Versions
• Licenses

A reliable SCA tool can also identify known security vulnerabilities and dependencies in the detected components. These vulnerabilities are cross-referenced against a known database, such as the National Vulnerabilities Database (NVD) maintained by the National Institute of Standards and Technology (NIST).

The tool continuously tracks these vulnerabilities during development, and updates the SBOM. It can also be integrated into a continuous integration/continuous delivery (CI/CD) pipeline to keep the SBOM updated.

What Is a CBOM and How Does it Differ From an SBOM?

In October 2018, the U.S. Food and Drug Administration (FDA) published an updated draft of Premarket Cybersecurity Guidance to manage cybersecurity for medical devices via a Cybersecurity Bill of Materials (CBOM). The aim was to get medical device manufacturers to submit a list of commercial, open source, and off-the-shelf software and hardware components. The CBOM would help medical device users to:

• Effectively manage their assets
• Understand the potential impact of identified vulnerabilities
• Take action to maintain the device’s performance

The CBOM would contain the list of proprietary and open source software components, version numbers, and licenses.

So a CBOM is very similar to an SBOM. Moreover, like an SBOM, a CBOM can also be integrated into the device development lifecycle to identify third-party components that contain vulnerabilities. A CBOM can also be cross-referenced against the NIST’s NVD to automate vulnerability monitoring and alerting.

The CBOM, however, also contains a list of hardware components, so it aims to minimize supply chain attacks from both software and hardware fronts.

Protect Your Business From Vulnerabilities With ZenGRC

Identify the vulnerabilities across your critical infrastructure, and take action to mitigate them — with ZenGRC. ZenGRC is an integrated vulnerability management platform that provides a single source of truth for modern organizations with a broad software footprint.

Schedule a free demo to learn how ZenGRC can bring value to your cybersecurity and information security program.