While the drumbeat for the widespread adoption of software bills of materials (SBoM) in IT environments grows louder, the reality remains that relatively few companies are consistently implementing SBoMs to track the software components used in their application portfolios.
A Recent study by ReversingLabs, conducted by Dimensional Research, found that less than a third of companies are using SBoMs today. Among those, half said the process of creating and verifying SBoMs involves manual steps — a tedious process when there may be thousands of pieces of code in the mix.
Still, security professionals increasingly believe that SBoMs are a fundamental step in understanding and managing risk in the software supply chain. Modern development practices have led most software development teams to avoid reinventing the wheel when building common functionality into their software, instead using open source libraries and packages already developed by the community. This makes their work faster and more predictable, but if there’s no control or transparency over what components they’re using, the risk of vulnerabilities can quickly become unmanageable.
SBoMs help development teams understand what code is working under the hood of their applications and identify when underlying components are proving vulnerable.
Given the low prevalence of SBoMs reported by ReversingLabs survey respondents, it should come as no surprise that almost half of them also admit they are unprepared to protect their software from supply chain attacks.
Application security advocates in industry groups, open source communities, and government agencies alike are involved in efforts to increase the adoption of SBoMs and in turn improve the state of security of the software supply chain. In recent weeks, these groups have launched three separate initiatives aimed at increasing not only the rate at which SBoMs are generated, but also the effectiveness with which companies 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 bringing together members of the software and security communities to discuss how to improve SBoM best practices and standards can become.
“CISA believes that the concept of SBOM and its implementation need further refinement,” the agency wrote in a federal register post. “The work to scale and operationalize the SBOM implementation should continue to be driven by a broad community initiative and not dictated by any particular entity.”
Topics for the listening session, which CISA will moderate, 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 to improve the state of open source and commercial software worldwide.
Recommended priorities included establishing SBoMs everywhere by focusing on improving SBoM tools, training and advocacy across the industry to normalize the creation and use of SBoMs.
“The more ubiquitous SBOMs are, the more valuable they can be to industry. In general, we believe that SBOMs should be created automatically via well-validated tools every time software is created or distributed,” the document explained. “To get to the point where SBOMs are ubiquitous in software distributions, we need to remove all the friction for adoption.”
The Linux Foundation and OpenSSF plan to invest $3.2 million in their first year of work on this SBoM initiative.
OWASP CycloneDX API rollout
In order to create an easily operationalizable SBoM, software and security teams need a consistent and standardized way of communicating BOM information – including everything from license and copyright information to security-related metadata such as versioning.
The two most important 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 advance the SPDX standard. Meanwhile, OWASP continues to move the ball forward with OWASP. Most notably, OWASP released the draft version of a new one last month BOM Exchange API This is intended to standardize how BOMs are published and retrieved independently of the software ecosystem.
“Many products and tools are 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 yet,” says Patrick Dwyer, co-leader of the CycloneDX standard. “With the release of this API specification, products and tools can begin to transfer this data in a standardized way, allowing for broader out-of-the-box integration across the SBOM product and tool ecosystem.”