All SBOMs are not created equal: What's required for them to be effective

With some help from the federal government, software bills of materials (SBOMs) have become an important tool for security teams looking to secure their software supply chains. However, while SBOMs can provide transparency into the components that all combine in a complex process to make up a software package, one thing is clear: Not all SBOMs are created equal. Some can be meticulous and comprehensive, while others are little more than a checkbox.

Getting the SBOMs right is a critical aspect of securing the software you develop or buy, and they have never been more important because of new initiatives. Secure by Design, for example, aims to shift the way software is built from the start, with the ultimate goal of shifting liability for software lapses from buyers to builders. As the National Security Agency noted in December:

SBOMs and SBOM management tools play a part in enforcing the requirement to make software secure by design as they provide a mechanism to determine software component risk and establish a level of confidence in the software’s freedom from vulnerabilities.

National Security Agency

However, a variety of variables can influence what will be incorporated into an SBOM, including the tools used to generate them, the method of generation (static or dynamic), the level of granularity, and the level of adherence to SBOM standards such as SPDX, Cyclone DX, Tern, and Syft.

Michael Amiri, a senior digital security analyst with ABI Research, said SBOMs also serve a variety of purposes. "Some organizations might use SBOMs for legal compliance, and others might focus more on identifying security threats in their software chains. Based on such specific needs, SBOMs might have different characteristics and areas of focus," he said.

How an SBOM is created, with tools or manually, will also influence what it looks like. Tools have a wide variety of outputs, said Sean Wright, head of application security at Featurespace.

Even if they follow standards, they may deviate slightly from the standard. And if SBOMs are created manually, it is unlikely that they would adhere to any of the existing standards.

Sean Wright

Here are the main challenges with SBOMs, how tooling affects their usefulness — and what it will take to make them effective at securing your software supply chain.

Get White Paper: Go Beyond the SBOM to Bring Control to Third-Party Software Risk

Interoperability concerns plague SBOM effectiveness

The absence of a unified standard for the format and structure of SBOMs presents significant challenges within the software industry. "This lack of standardization leads to inconsistencies in the content and presentation of SBOMs across various tools, platforms, and organizations," said David Lindner, CISO of Contrast Security. "Interoperability becomes a notable concern, as SBOMs generated by different tools often use disparate terminology, data structures, and encoding methods. Integration complexity also creates more issues, as organizations navigate the challenges of translating or mapping SBOM data between different formats, increasing the risk of errors."

Overall, the absence of a standardized SBOM format adds to confusion, inconsistency, and fragmentation within the software ecosystem.

David Lindner

Matt Rose, field CISO at ReversingLabs, said the timing of when an SBOM is created will also influence its contents. "A lot of times, someone will create an SBOM at one release cycle but not update it again," he explained. "Every time you release software in a modern CI/CD orchestration, there should be an SBOM. If there's 10 releases in a day, there should be 10 SBOMs, because there are new components, new capabilities, within that application that could change."

Generating an SBOM as part of your CI/CD DevSecOps release process is paramount to an effective SBOM as you release software and applications.

Matt Rose

Dependency visibility remains slippery

There are three points in the software development lifecycle where SBOMs are commonly generated: before the software is built, after it's built, and during runtime. "Each of these methods offers unique advantages and challenges," Lindner said.

Pre-build SBOMs allow organizations to anticipate dependencies and potential security vulnerabilities early in the development process but may include many libraries not actually used after being built and running in production. Post-build SBOMs provide a snapshot of the dependencies included in the compiled application but may miss out on transient dependencies that are not explicitly linked. Runtime analysis, on the other hand, offers the most accurate representation of the software's dependencies in a real-world environment.

David Lindner

Another factor contributing to SBOM variation is the tools used to create them, said Mike McGuire, product marketing manager for Synopsys' Software Integrity Group. Different tools and processes, used at different times of the software development lifecycle (SDLC), will yield different SBOMs. "Even using the same tools and processes can result in different SBOMs should component inclusion criteria differ from one to the other," he said.

Different tools will vary in their ability to identify the dependencies that might be included in an SBOM. Some tools may just mirror the dependencies listed by a package manager artifact, while others will do the extra work to identify indirect and undeclared dependencies.

Mike McGuire

What makes a good SBOM tool?

In its advice on SBOM management, the NSA outlines that an SBOM tool should have the following capabilities:

• Support and manage all SBOM formats, such as Cyclone DX and SPDX.
• Support import of JSON, XML, or CSV file types.
• Check SBOM structure and syntax for compliance with a format's specifications.
• Display information about an SBOM's compliance with the structure and syntax rules for an SBOM's format and version.
• Include an auto-correction option to assist a user in normalizing and correcting an imported SBOM.
• Support export of an SBOM in Cyclone DX or SPDX, as well as in JSON, XML, or CSV.
• Support format and file conversions of an SBOM.
• Aggregate multiple SBOMs from the tool's repositories into a single SBOM.

Tooling is an incredibly important choice, Wright said.

"Most SBOMs will be generated by tooling, so making sure that the tooling generates an accurate and supported SBOM is vital."
—Sean Wright

How SBOM tools differ

SBOM can vary in terms of their purpose. Amiri said that one tool, FOSSA for example, might be better in detecting open-source components in software through deep scanning techniques, so it will be better at highlighting solutions for license and legal compliance.

Other tools, such as Black Duck, will excel at identifying threats and open-source vulnerabilities, providing a better security scanning of software supply chains, he continued, while a tool such as WhiteSource will use an integrated and balanced approach that considers both security and legal compliance into its SBOMs.

Bud Broomhead, CEO of Viakoo, said SBOMs are critical to addressing two threat vectors that have grown dramatically in the last couple of years — open-source and IoT/OT vulnerabilities — even though the tool doesn't assess the severity of the vulnerabilities it exposes, he said.

SBOMs are an important component of a "healthy software ecosystem" but are by no means the only factor, said Alex Kreilein, vice president of product security at Qualys.

While the SBOM is an effective output, it cannot be trustworthy if the system that created it cannot validate the provenance of the product. It’s critical for organizations to understand the whole supply-chain from code through pipeline to production.

Alex Kreilein

Go beyond SBOM creation — make them actionable

Rose said that while SBOMs can serve a variety of purposes, if your goal is improving your organization's software supply chain security posture, they must go beyond a single purpose. SBOMs must be comprehensive and accurate (to address the increasingly complex software development process) — and actionable.

Upgrading your application security tools is essential to creating next-generation SBOMs, Rose said. Complex binary analysis provides visibility into the complete software package, which can make them more actionable.

SBOMs can help in a lot of ways because they give a list of all the ingredients in a software package. But they don't give you information on how these ingredients interact.

Matt Rose

He said that complex binary analysis allows for SBOMs to deliver the following features:

• A software quality grade for each component so you know at a glance where major issues need remediation.
• Insight into indicators of supply chain compromise, such as software tampering, malware, ineffective mitigations, or certificate signing issues.
• Remediation advice and prioritization that helps teams focus on the most important software security improvements.