Software bills of materials (SBOMs) have long been seen as the technical foundation for opening up visibility into enterprise software supply chains. So far, the work has been focused on building the mechanisms for collecting and updating the software ingredients within SBOMs and organizing everything in a repeatable, standardized fashion.
That's a good start, but before enterprises and the software community can truly start operationalizing SBOMs, shareability of the components in SBOMs needs to be developed. And many stakeholders, including software engineers, application security (AppSec) professionals, and individuals working on the legal and compliance side of things are going to have to work together to establish the technical and policy frameworks for making SBOMs more easily shareable.
John Bambenek, president at security firm Bambenek Consulting, said that if SBOM data isn't easily accessible across organizational lines, producing SBOMs is just "meaningless work."
"Ultimately, SBOMs are a way for an organization to know if applications they are using have vulnerabilities in one of its components. It isn’t a tool for software developers; it’s a tool for their customers."
—John Bambenek
To do it right, development teams need to plan ahead and create shareable SBOMs that are standardized in a format that's readily consumable while also establishing scalable systems for attestation, access management, and data verification, among other factors. Along the way, they'll need to grapple with risk management concerns that come with the territory of sharing sensitive data.
Two recent events should ease the path to SBOM sharing. First, the OWASP Foundation released Cyclone DX 1.6, which introduced a machine-readable approach to managing SBOMs with CycloneDX Attestations (CDXAs). Second, a U.S. Cybersecurity and Infrastructure Security Agency (CISA) working group that is focused on SBOM sharing and exchange produced two documents, an SBOM Sharing Primer and an SBOM Sharing Roles and Considerations report.
Here are key concerns — and why data sharing is essential to making SBOMs actionable to improve your organization's software security.
[ Learn why you should go beyond SBOMs with our Special Report. Plus: Learn how with our White Paper ]
The pros and cons of shareable SBOMs
Shareable SBOM detractors point to the risk to intellectual property. They argue that, when it hands over so much information about its codebase through an SBOM, a company is giving away its software IP.
John Gallagher, vice president for Viakoo Labs, a research and content-generation team within Viakoo, acknowledged that there are a few risks with SBOMs, most notably that they deliver much more detail about your product than you would traditionally disclose — and can even provide threat actors with critical information on vulnerabilities that can be exploited only in the context of other software components.
"Examples of this include giving competitors insight into technology tradeoffs, proprietary code, or development processes, or giving threat actors advantages in developing vulnerabilities for specific systems, such as critical infrastructure."
—John Gallagher
However, these concerns should be thought about in risk management terms, Gallagher said. He and many others argue that the ability of shared SBOMs to mitigate risks in most cases outweighs the risks they might expose. That is especially true considering that SBOMs are probably an impractical route for a corporate spy to take to achieve their aims.
Chris Blask, vice president of strategy at Cybeats, said companies generally have many ways to protect IP, including contracts and lawyers. And partners are less of a risk than the detractors think, he added.
"[If] I've got all my competitors' intellectual property or code at any given moment, I probably wouldn't even look at it. I have enough problems on my own. So I think the risk is overstated."
—Chris Blask
With vulnerabilities that are notoriously hard to find and remediate — such as those within IoT systems — the use of SBOMs can dramatically improve defenses, Blask said. "This time advantage far outweighs theoretical advantages to either competitors or threat actors."
Meanwhile, most bad guys already have a lot of tried-and-true mechanisms for rapidly churning out zero-day or Nth-day exploits, Bambenek said. That being the case, the need by the software development community for shareable SBOMs outstrips the risk of sharing.
"The adversaries are always a step ahead of knowing what is vulnerable, as they are producing zero-day exploits all the time. Software developers need to be aggressive in checking for vulnerabilities in their components and libraries as well as monitoring external repositories for updates."
—John Bambenek
SBOM standardization and access logistics
As the software industry starts to overcome those common objections to sharing SBOMs, it will need to think more dynamically about the logistics around sharing. Said Blask, "The conversation has traditionally been, 'I make software, therefore I make SBOMS. You buy my software, therefore I may or may not give you my SBOM.' We're starting to see that it's more complicated than just that one-to-one sharing relationship," he said.
Blask is one of a handful of experts who worked with the CISA on SBOM sharing and exchange and who helped to develop the agency's primer and guidelines on shareable SBOMs. One key takeaway from that work for Blask is that, in the SBOM sharing ecosystem, the author of the SBOM may not necessarily be the producer of the software. Meanwhile, the SBOM consumer may not always be the end customer of that software. That consumer could potentially be, for example, a lawyer for the procurement department, an auditor, or an insurance underwriter.
The CISA also defined a third participant in the exchange, the SBOM distributor — which, again, is a role not necessarily aligned with that of the software distributor. SBOM distributors could be middlemen or organizations that help facilitate exchange between a wide swath of different SBOM authors and consumers.
As organizations share SBOM information, they'll have to figure not just the roles, but also ways to manage the sharing of SBOM content dynamically — and in line with policy.
The industry needs to move beyond checkbox SBOMs, Blask said. Software consumers need to know the software that was running on the machine tool that the subcontractor used, for example, because they need to know if some of that software contained a weak link. "That's where we're going with all this supply chain transparency stuff," he said.
Different regulations and different contracts with vendors will call for new requirements on how deep SBOM content needs to go. What's more, like enterprise code that is shying away from a monolithic model, so too will SBOM content. There will rarely be one singular SBOM shared out for a big application. Instead, different content will be shared based on either direct requests or compliance demands. This is going to take some hard thinking and resources from SBOM producers to manage over time, and it could be an area for innovation from industry players on helping to formulate tools and frameworks to do this more easily, Viakoo's Gallagher said.
"Ensuring that shared SBOMs meet all regulatory standards can be complex and resource-intensive. Large and complex SBOMs can be difficult to manage, share, and understand, especially for systems with numerous dependencies and transitive components."
—John Gallagher
In addition to managing what content goes in which shared SBOM, there's also the age-old problem of standardization in how SBOMs are formatted — and the terminology they use for different components.
Kevin Scribner, product manager at Synopsys Software Integrity Group, said the biggest challenge he's heard about from customers is component identification.
"There is no standardized method to identify software packages/components, so the industry has used incomplete or a combination of tool-specific identifiers, PURL, and CPE. Getting involved in working groups to help solve the problem as well as having tools that use a layered or combined identification process can help."
—Kevin Scribner
The future of SBOM sharing
Ultimately, the future of SBOM sharing will require not only well-managed and standardized SBOM content, but also more coordination and intermediary systems to help figure out access rights and data validation. "We need to automate policy," Blask said. "We have to build up automated policy systems because the most radical thing about radical transparency is that not everything should be transparent."
Policy defines the circumstances of when certain things are shared with certain SBOM consumers. That policy may be defined by regulators, but it is most often going to be defined by procurement offices and contractual relationships — both those between customers and vendors and the other business relationships upon which modern digital ecosystems are built. It’s already starting to happen. It’s very likely that insurance underwriters will start to require use of SBOMs as a condition of offering cyber-insurance, Blask said.
He foresees multiple marketplaces and SBOM sharing repositories that can coordinate sharing with a policy-based access management mechanism baked in that makes the sharing relationship traceable, verifiable, and protected. "This is where the dreaded B-word, blockchain, can be used. If that's important enough to you, a distributed ledger is a mechanism for perhaps being really, really certain that it has not been shared with somebody else," Blask said.
However these sharing mechanisms evolve, hopefully this will help alleviate the apprehension about sharing enough information to help software supply chain stakeholders meaningfully reduce risk, Scribner said.
"At first, organizations were very apprehensive about sharing SBOMs and only included the minimum requirements. As tooling to help control the content of the SBOM and related processes matures, organizations will likely feel more comfortable sharing this data with their customers."
—Kevin Scribner
