Gathering Momentum: 3 Steps Forward to Expand SBOM Use

While the drumbeat grows louder for widespread adoption of software bills of materials (SBOM) in IT environments, the reality remains that relatively few organizations consistently implement SBOMs to track the software components used within their application portfolios.

A recent study by ReversingLabs, conducted by Dimensional Research, found that less than a third of companies today use SBOMs. Among those, half said the process of generating and reviewing SBoMs involve manual steps – an onerous process when there are thousands of pieces of code potentially in the mix.

Still, security experts increasingly believe that SBOMs are a foundational step for understanding and managing software supply chain risks. Modern development practices have pushed most software engineering teams to avoid reinventing the wheel when building common functions into their software and instead use open source libraries and packages that have already been developed by the community. Doing so makes their work faster and more predictable, but if there’s no governance or visibility into which components they use, the risk from vulnerabilities can quickly grow unmanageable. 

SBOMs help development teams understand what code is operating under the hood of their applications and to pinpoint when underlying components are found to be vulnerable.

Given the low prevalence of SBOMs reported by the ReversingLabs survey participants, it should come as no surprise that nearly half of them also admit they’re unprepared to protect their software from supply chain attacks.

Application security advocates in industry groups, open source communities, and government agencies alike are all involved in efforts to increase the prevalence of SBOMs and, in turn, improve the state of software supply chain security. In the past several weeks, these groups have launched three different initiatives aimed at not only boosting the rate at which SBOMs are generated, but also the effectiveness in how organizations use them to protect their software.

CISA Listening Groups

Last week the Cybersecurity and Infrastructure Security Agency (CISA) announced a series of public listening sessions scheduled for July aimed at gathering members of the software and security communities to discuss how to improve SBOMs best practices and standards.

“CISA believes that the concept of SBOM and its implementation need further refinement,” the agency wrote in a Federal Register post. “Work to help scale and operationalize SBOM implementation should continue to come from a broad-based community effort, rather than be dictated by any specific entity.”

The listening session topics that CISA will facilitate include cloud and online applications, sharing and exchanging SBOMs, tools and implementation, and on-ramps and adoption.

OpenSSF Action Plan

Last month at the Open Source Software Security Summit in Washington, DC, the Linux Foundation and the Open Source Security Foundation (OpenSSF) unveiled a 10-point security mobilization plan for improving the state of open source and commercial software worldwide.

Among the recommended priorities was getting SBOMs in place everywhere by focusing on improving SBOM tooling, training, and advocacy across the industry to normalize SBoM creation and consumption.

“The more ubiquitous SBOMs are, the more valuable they can be to the industry. Generally, we believe that SBOMs should be produced automatically via well-vetted tools every time that software is built or distributed,” the document explained. “To get to the point where SBOMs are ubiquitous in software distributions, we need to remove all friction for adoption."

The Linux Foundation and OpenSSF are planning on targeting $3.2 million in investments in the first year of their work on this SBOM initiative.

OWASP CycloneDX API Rollout

In order to create an easily operationalized SBOM, software and security teams need a consistent and standardized way to communicate bill-of-materials information – including everything from licensing and copyright information to security-related metadata such as versioning.

The two major choices of standards on this front are SPDX (a Linux Foundation Project) and CycloneDX, a lightweight SBOM standards project by OWASP. The OpenSSF action plan will continue to refine and move forward the SPDX standard. Meantime, OWASP continues to move the ball forward with OWASP. Most notably, last month OWASP launched the draft version of a new BOM Exchange API that’s designed to standardize how bills of materials are published and retrieved independent of the software ecosystem.

“There are lots of products and tools being released that support the production and consumption of SBOMs in standard data formats, but we haven’t had a standard way to transfer SBOMs between systems,” says Patrick Dwyer, co-leader of the CycloneDX standard. “With the release of this API specification, products and tools can start transferring this data in a standard way, enabling greater out-of-the-box integration across the SBOM product and tool ecosystem.”