SBOMs: What they are and why organizations need them

In the continuously rippling wake of cyberattacks, hacks and ransomware, organizations want — and need — to clean up their software supply chains. 

In this, they are increasingly turning to a valuable visibility tool: the software bill of materials (SBOM). 

As noted by the Cybersecurity and Infrastructure Security Agency (CISA), SBOMs have “emerged as a key building block in software security and software supply chain risk management.” 

What is an SBOM?

If you’ve worked in engineering or manufacturing, you’re already familiar with a bill of materials, or BOM, which is a list of all the parts needed to manufacture a specific product – from raw materials to subcomponents and everything in between, along with quantities of each one needed for a finished product. An SBOM, then, is a BOM for software. CISA defines an SBOM as a “nested inventory, a list of ingredients” that make up software components. 

According to the U.S. Department of Commerce, SBOMs should offer a complete, formally structured, machine-readable list of these components, as well as libraries and modules required to build the software, the supply chain relationships between them, and their given vulnerabilities. Notably, SBOMs provide insight into the makeup of software created by open-source software and third-party commercial software. 

Biden’s Executive Order on Improving the Nation’s Cybersecurity served as a wake-up call of sorts for federal software suppliers when it comes to SBOMs. They must now implement them and adhere to minimum elements within. 

And many experts are increasingly urging private software suppliers to do the same. 

Why implement them? 

In writing (ideally secure) applications, developers check code they’ve written to ensure there are no logic errors or coding mistakes. Still, today’s applications are often a conglomeration of proprietary code as well as open-source and third-party components — one application, for instance, may be a mix of dozens of such components. 

But this third-party commercial and open-source software can be limited in visibility. And attackers are increasingly exploiting this by targeting vulnerabilities that organizations are unable to uncover in third-party libraries because they don’t have full visibility. Thus leading to incidents such as the Log4j vulnerability and the SolarWinds software supply chain attack.

An annual survey by the Synopsis Cybersecurity Research Center of 2,409 codebases revealed that 97% contained open-source components. It also revealed that 81% of these codebases had at least one known open-source vulnerability and that 53% contained license conflicts. 

With organizations responsible for their software development chains — proprietary, open-source and third-party code alike — security and risk management leaders are seeking solutions that not only help to mitigate product security risk and supply chain risk, but that shortens time-to-market, automate incident response, and assist with compliance requirements, according to Gartner’s 2022 Innovation Insight for SBOMs Report. 

“SBOMs represent a critical first step in discovering vulnerabilities and weaknesses within your products and the devices you procure from your software supply chain,” write report authors Manjunath Bhat, Dale Gardner and Mark Horvath. SBOMs allow organizations to “de-risk” the vast amounts of code they create, consume and operate. 

SBOMs “improve the visibility, transparency, security and integrity of proprietary and open-source code in software supply chains,” according to the report. The firm advises software engineering leaders to integrate the tool throughout the software delivery lifecycle. 

Improving the quality of software better prepares organizations to thwart adversarial attacks following new open-source vulnerability disclosures like those tied to Log4j, according to the Linux Foundation Research team. 

Also according to Linux research: 

• 51% of organizations say SBOMs make it easier for developers to understand dependencies across components in an application. 
• 49% say SBOMs make it easier to monitor components for vulnerabilities. 
• 44% say SBOMs make it easier to manage license compliance.

They are “an essential tool in your security and compliance toolbox,” as contended by Bhat, Gardner and Horvath of Gartner. “They help continuously verify software integrity and alert stakeholders to security vulnerabilities and policy violations.” 

Use case, explained

Given that an SBOM contains components used in an application, the first question to answer is why an organization needs that information, explained Tim Mackey, principal security strategist at Synopsys. Often the answer is that they don’t want to fall victim to a Log4Shell style attack, he said. 

So, that simple patch management statement implies that a process exists that analyzes all software for usage of Log4j, then maps that usage back to a database of vulnerable versions of Log4j. If the version of Log4j found in the application is discovered to be vulnerable, a notification is sent to programmers and, ideally, the problem is fixed. 

But “this entire workflow falls apart,” he said, if there is any software that wasn’t analyzed, if the vulnerability database is out of date, or if there is a problem in the mapping of identified versions to vulnerable versions. 

Mackey underscores the fact that, unless an organization can confidently state that their patch management processes cover all software, they need an SBOM.

“Absent such information,” he said, “it’s very hard for any organization to defend against cyberattacks targeting third-party software components.”

A growing enterprise practice

According to Gartner, by 2025, 60% of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs in their software engineering practice. That reflects an increase of roughly 20% compared to 2022. 

The Linux Foundation Research team revealed that 78% of organizations expect to produce or consume SBOMs in 2022 — up 66% from 2021. The team also reported that additional industry consensus and government policy will further drive SBOM adoption and implementation. 

An increasing number of providers are emerging to help organizations build SBOMs. They include Anchore, Mend, Rezilion, Aqua and Synopsys. 

The increased benefit of SCAs

But while there is renewed interest in SBOMs following Biden’s order, the concept has been in wide use in the software composition analysis (SCA) security market for years, Mackey contended. Vendors in the market use SBOMs to identify unpatched open-source vulnerabilities.

Also, the SBOM workflow can commonly be found in SCA tools. The SCA market is a mature one with many vendors, said Mackey. 

While there is “intense focus” on the concept of an SBOM, it’s not always recognized that an SBOM is simply a file listing the elements that make up an application. 

It doesn’t contain information related to vulnerabilities, functionality, serviceability or even the age of the component. That information needs to come from other sources uncovered by tools such as SCAs, he said, and it must also be supported by workflows. 

Simply put, “without those sources and workflows, an SBOM is no more effective than telling someone who doesn’t know they need to change the oil in their car regularly the chemical composition of motor oil,” said Mackey.