SBOMs: what are they and why do organizations need them

In the constantly rippling wake of cyber-attacks, hacks and… ransomwareOrganizations want and need to clean up their software supply chains.

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

As noted by the Agency for Cybersecurity and Infrastructure Security (CISA), SBOMs have “emerged as an important building block in software security and risk management of software supply chains.”

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 sub-components and everything in between with quantities of each needed. are for a finished product. An SBOM is therefore a bill of materials for software. CISA defines an SBOM as a “nested inventory, a list of ingredients” that make up software components.

According to the US Department of Commerce, SBOMs should provide a complete, formally structured, machine-readable list of these components, as well as libraries and modules needed to build the software, the supply chain relationships between them and their given vulnerabilities. In particular, SBOMs provide insight into the composition 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 vendors when it comes to SBOMs. They now have to implement them and stick to the minimal elements inside.

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

Why implement them?

When writing (ideally safe) applications, developers check the code they’ve written to make sure there are no logic or coding errors. Yet today’s applications are often a conglomeration of proprietary code, as well as open-source and third-party components – for example, one application can be a mix of dozens of such components.

But this commercial and open source third-party software may have limited visibility. And attackers are increasingly taking advantage of this by targeting vulnerabilities that organizations cannot discover in third-party libraries because they are not fully exposed. This leads to incidents such as the Log4j vulnerability and attack on the SolarWinds software supply chain.

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

With organizations responsible for their software development chains — both proprietary code, open source, and third-party code — security and risk management leaders are looking for solutions that not only help reduce product security and supply chain risks, but shorten lead times. market, automate incident response and assist with compliance requirements, according to Gartner’s 2022 Innovation insight for SBOMs Report.

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

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

Improving software quality will better prepare organizations to fend off hostile attacks following new open source vulnerability disclosures, such as those related 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 between components in an application.
• 49% say SBOMs make it easier to check components for vulnerabilities.
• 44% say SBOMs make it easier to manage license compliance.

They’re “an essential tool in your security and compliance toolbox,” as Gartner’s Bhat, Gardner, and Horvath claim. “They continuously help verify software integrity and alert stakeholders to security vulnerabilities and policy violations.”

Usage example, explained

Since an SBOM contains components that are used in an application, the first question to answer is why an organization needs that information, explains Tim Mackey, chief security strategist at Synopsys. Often the answer is that they don’t want to fall victim to a Log4Shell-like attack, he said.

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

But “this whole workflow falls apart,” he said, if there’s software that hasn’t been analyzed, if the vulnerability database is outdated, or if there’s a problem mapping identified versions to vulnerable versions.

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

“In the absence of such information,” he said, “it is very difficult for any organization to defend itself against cyber-attacks targeting third-party software components.”

A growing business practice

According to Gartner, by 2025, 60% of organizations that build or acquire critical infrastructure software will mandate and standardize SBOMs in their software engineering practice. That is an increase of about 20% compared to 2022.

The Linux Foundation Research team revealed that 78% of organizations expect to produce or consume SBOMs by 2022 – a 66% increase from 2021. The team also reported that additional industry consensus and government policies will further drive SBOM adoption and implementation. stimulate.

More and more providers are emerging to help organizations build SBOMs. They contain anchor, to recover, Resistance, aqua and Synopsys.

The Greater Advantage of SCAs

But while there has been renewed interest in SBOMs following Biden’s order, the concept has been widely used in the software composition analysis (SCA) security market for years, Mackey claimed. Vendors in the market are using SBOMs to identify unpatched open source vulnerabilities.

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

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

It does not contain any information regarding vulnerabilities, functionality, usability or even the age of the part. That information should come from other sources discovered by tools like SCAs, he said, and it should also be supported by workflows.

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