What Is a Software Bill of Materials?

What Is a Software Bill of Materials?

Ed Moyle, systems and software security director at Drake Software and member of the ISACA Emerging Trends Working Group, defines a software bill of materials as “a manifest of things — software components and dependencies — within a piece of software.” Because software is not always created from scratch but can be drawn from various commercial or open-source components, the bill of materials provides a full list of what’s inside, typically after the software is completed.

The SBOM also helps track dependencies, inter-dependent relationships between software components that help them function. Tracking those is no small challenge. “This is harder than it sounds because each dependency has its own set of dependencies,” says Moyle.

Thankfully, that’s why most SBOMs are autogenerated. “There are scanning tools that do the job of scanning a piece of software to identify all the dependencies it has — including the less obvious pieces — in building out a software bill of materials,” says Al Gillen, group vice president for software development and open-source research at IDC.

WATCH: Learn how diversifying your supply chain can enable revenue.

What Goes into a Software Bill of Materials?

The National Telecommunications and Information Administration has created a useful standard for what should go in an SBOM. They cover three primary areas:

1. Data fields: These spell out basic information about software components, including supplier name, component name, component version, unique identifiers, dependency relationships, software bill of materials author and time stamp.

2. Automation support: A software bill of materials is required to be in a machine-readable format such as SPDX, SWID tags or CycloneDX. That’s important because creating a software bill of materials is too difficult for a human to do alone. “Trying to track all dependencies manually would be tremendous work, if not ultimately impossible,” says Moyle.

3. Practice and processes: This element details the specifics about the use of a given software bill of materials, such as how it is distributed, how it deals with mistakes, and how it identifies unknown elements in software components.

What Is the Purpose of a Software Bill Of Materials?

“The goal is to provide transparency into the composition and provenance of software,” says Moyle. “For the customer, you can trace the provenance and composition of what you own, and the developer can keep track of what's in their dependencies so they can offer more transparency to their customers.”  

It’s also important for managing potential risk. SBOMs are often compared with nutritional information labels that list all the ingredients contained in a food item. The reason for that? “Consider the experience of someone allergic to a commonly occurring ingredient like soy. Obviously, they’d avoid products that make first-order use of soy — products that are obviously made out of it, like tofu,” says Moyle. “But what about second- and third-order usage? For example, a cake with chocolate icing where the chocolate in the icing uses soy lecithin as an emulsifier. They’d still need to know about that, right?  Even a small dose of the allergen can be problematic depending on the severity of the allergy.”

How does that tie to SBOMs? “In some situations, dependencies in software can introduce risk in a similar way; for example, when there are severe vulnerabilities in commonly occurring and widely deployed software components,” says Moyle.

MORE FROM BIZTECH: Learn key lessons about protecting your organization from cyberattack.

How do SBOMs Help Protect the Software Supply Chain?

“SBOMs help make it possible to protect your supply chain because they identify what is included in your supply chain,” says IDC’s Al Gillen. It’s like surveying your home for vulnerable access points to know where to install alarm sensors. By providing insights into software components, organizations may not merely identify potential risks but, ideally, identify them early enough that they don’t make it to a final product.

That protection will be imperative as supply chains become increasingly vulnerable. “In 2021, the European Union Agency for Security estimated that the number of attacks on the supply chain would increase fourfold from the previous year,” Worthington says. When all it takes is a single vulnerability to disrupt a supply chain, knowing what that vulnerability might be — and how to eliminate it — is critical.

Experts caution, however, that SBOMs aren’t foolproof. “Collecting, managing, inventorying, and making use of the data from them is a large, complicated exercise,” says Moyle. “Yes, it makes the problem of software vulnerabilities potentially more manageable, but it’s not magic and won't fix all problems.” Worthington agrees: “An SBOM is only a piece of the puzzle. Securing your software supply chain requires people, process and technology.”

Because SBOMs can be code heavy, reproducing a sample here would be difficult. However, those interested can find a few examples provided by Worthington at Github, SPDX and the NTIA.