The security and DevOps world is at a fever pitch with proselytizing software bills of material (SBOM). In theory, SBOMs can help organizations bolster their efforts in application security, vulnerability management — and software supply chain security. But as with any emerging security initiative, the practical realities of SBOM usage has not matched the hype.
Gartner said in a recent research note that as of last year, fewer than 20% of organizations developing or procuring critical infrastructure software mandated and standardized on SBOMs. The rate is likely much lower across the broader software development community.
Clearly, most organizations have barely started on their SBOM journey. While Gartner is bullish that many organizations are going to be hurtling forward quickly — saying SBOM use will break 60% by 2025 — the path toward SBOM success is riddled with pitfalls and uncertainties.
Here's what leading experts say about some of the biggest obstacles organizations will run into as they try to get the most out of their SBOM investments.
[ Learn how you can go beyond the SBOM with our Special Report. Plus: Download the White Paper ]
1. Lack of SBOM standardization
One of the most significant impediments to developing SBOMs is the absence of a standardized format for representing the information contained in the SBOM, said Scott Lard, partner at IS&T consulting Group.
"Different organizations and industries have different needs for what should be included in an SBOM and how it should be structured. As a result, there is no universal format that everyone can use, making sharing SBOMs across different systems and organizations difficult."
—Scott Lard
The two main contenders for formats are CycloneDX from OWASP and SPDX from Linux Foundation, but then there are other niche formats like SWID, which is popular in hardware manufacturing, and Syft, a newer format for containers. As Lard explains, the lack of a single standard can lead to confusion and inconsistency. And it makes it tough to track and manage software components across the supply chain.
"Building out SBOMs becomes more complex and time-consuming in the absence of a standardized format."
—Scott Lard
2. Incomplete or inaccurate data from SBOM tools
With the tools landscape for generating SBOMs rapidly evolving, organizations need to be careful about the tools they use produce SBOMs, to ensure that they're not depending on incomplete or inaccurate data, said Loreli Cadapan, Chief Product Officer at ActiveState.
"The challenge for some of these tools is the ability to generate an SBOM of all of your open source dependencies, including the transitive dependencies all the way down the dependency graph. And developers may pull pre-compiled binaries from public repositories into their codebases, which could make it difficult to produce a complete SBOM."
—Loreli Cadapan
SBOMs are also liable to be inaccurate, outdated or even tampered with, Cadapan said. "To address this challenge, teams should ensure that their SBOMs are managed properly from the beginning, complete with strong cryptographic enforcement, as well as maintain their SBOMs throughout the development lifecycle to keep them updated," she said.
3. Inadequate SBOM resources, expertise — and automation
Because it is such a challenge to obtain complete and accurate SBOM data across all software components — requiring extra legwork in procuring a tapestry of tooling, integration, and in verification — organizations lacking adequate resources and expertise will be challenged to extract a lot of value out of SBOMs, said Kristen Demoranville, CEO of AnzenSage, a cybersecurity consulting firm for the food industry.
"As software supply chains become more intricate and interconnected, keeping SBOMs accurate and up-to-date demands a lot more resources, and that's definitely a challenge."
—Kristen Demoranville
Harman Singh, director at Cyphere, said organizations may not have the necessary expertise in-house to create accurate SBOMs, or to interpret and act on the information they provide.
Many organizations also struggle with meager automation and tooling, said Demoranville.
"We are frequently forced to use manual, error-prone techniques since there just aren't enough developed, automated tools to generate, maintain, and evaluate SBOMs properly."
—Kristen Demoranville
4. Making sense of data: Not enough context
Another one of the things that will keep security teams from getting the most out of SBOMs today — especially those provided by third parties — is the lack of context in which SBOMs are typically presented.
Tom Pace, co-founder and CEO of NetRise, an xIoT security firm, said that SBOMs are only "one artifact of the analysis most companies are providing." Other risks that can provide immediate value far and above a traditional SBOM includes expired certificates, private keys, weak default credentials and misconfigurations.
The problem: SBOMs are only one part of the visibility into software trust, explained Michael Mehlberg, CEO of the open source security firm Dark Sky Technology.
"In short, SBOMs tell you what ingredients are in your software, but nothing about the quality of those ingredients: the contributors, the quality control processes, the release processes, or code quality itself. To truly trust our software, we need to inspect the provenance beginning with the contributors and working all the way through the end product."
—Michael Mehlberg
5. Enriching SBOMs: The problem with VEX
The good news from the context perspective is that it is possible to enrich SBOMs with additional information and artifacts. For example, the Vulnerability Exploitability eXchange (VEX) format is a machine-readable artifact type that allows for communication about the exploitability of certain vulnerabilities found within a particular SBOM. It's particularly useful for winnowing down a big pool of flaws into only those that are actually reachable as the software is shown to be deployed in the SBOM.
The bad news is that generating that VEX is a cumbersome manual process, says DJ Schleen, distinguished engineer for Yahoo.
“When you hear (the word) “VEX,” that instantly says …“manual contextual information.” I have to actually go through things manually from a security perspective to say ‘Oh, this isn’t reachable.’ And that’s where VEX gets a little hairy.”
—DJ Schleen
6. Operationalizing SBOMs: No plans for 'what's next?'
Operationalizing SBOM information is one of the thorniest issues of all, according to a number of experts. Right now, there's not enough clear guidance on what to do after an SBOM has been generated, and vulnerabilities have been identified.
"In some cases that answer will be nothing, in other cases it will be to update the software package, reach out to the OEM, segment those devices or simply accept the risk. As always, the number of responses lay within a spectrum."
—Tom Pace
Doing that on a one-off basis is hard enough, but scaling the efforts by integrating SBOMs into a well-oiled DevSecOps workflow is what's really the issue for many organizations.
"Integrating them into existing workflows can be quite a task. Organizations must adapt their current software development and security processes, which might mean updating tools, policies, and training."
—Kristen Demoranville
7. It takes a village: Culture clash
As with so many other areas of application security and software supply chain security, SBOM success also hinges on that all-important collaboration between developers and security teams. Not only that, but there's a third group of stakeholders in the mix as well: suppliers. Culture clashes between any of these groups will inevitably be challenging for SBOM success.
"For effective SBOM management, we need software developers, security teams, and suppliers all working together, but that can be really hard to achieve in big, complex organizations."
—Kristen Demoranville
