The more cybersecurity leaders and software builders operationalize software bills of materials (SBOMs) to convey trust and transparency, the more they’re running into the traditional SBOM’s visibility limitations. As valuable as they are, SBOMs — as defined by the software industry — can offer only part of the software supply chain risk picture.
Modern software isn’t composed of open-source software components alone — it’s also dependent on a mesh of SaaS services, machine-learning models, AI agents, and specialized cryptographic assets. And all of these are not necessarily wrapped into SBOMs as they’re traditionally defined.
Dan Petrillo, vice president of product marketing for ReversingLabs (RL), said today's complex software packages require more complete transparency.
“The SBOM is really a misnomer. It’s not enough. It’s like if you asked for a bill of materials for a car and what you got was a plastics BOM that describes all of the plastic components in the car.”
—Dan Petrillo
A growing contingent in the software and security world now believes the industry should be following the stance of CycloneDX, which has been evangelizing for a broader BOM philosophy, Petrillo said.
CycloneDX project leader Steve Springett recently explained in an episode of the Application Security Podcast that, for whatever reason, the software industry, led first by the National Telecommunications and Information Administration and now by the U.S. Cybersecurity and Infrastructure Security Agency, has kept bills of materials mostly focused on software components.
"Software is more than just the libraries we depend on. It’s the services, the runtime environment in which it is executed, the cryptography algorithms. So it’s the whole enchilada.”
—Steve Springett
That's why CycloneDX evolved over the years to provide the flexibility to support any range of BOMs that can include hardware, cryptography, services, and more. “It started out as a bill of materials format, but if you look at all the capabilities of what it does, only about 35% to 40% is actually bill of materials-related. Everything else is more about software and system transparency,” Springett said. “It’s kind of evolving from a BOM standard to this transparency-expression language.”
Here are three essential xBOM categories that your software security team should see as core visibility tools for managing software supply chain risk.
[ Get the White Paper: Go Beyond the SBOM. And see the Webinar, Welcome CycloneDX xBOM ]
The xBOM is born
Following the lead of CycloneDX, software supply chain security advocates refer to all of the other bills of materials as part of the catch-all category of the extended bill of materials, or xBOM.
The idea is that the xBOM category should be able to flex into any growing software development specialty area outside the traditional SBOM's coverage of libraries and components.
First and foremost on the minds of software security leaders today is the risk ramifications of agentic AI. For example, buyers and builders of software need more reliable ways to inventory AI agents integrated into application infrastructure.
ML-BOMs
As innovators increasingly grapple with the prospect of securing the models, data flows, and code of AI and ML, governance and transparency are rapidly becoming requirements.
ML-BOMs and AI-BOMs will provide visibility into models and training data provenance that will be essential for satisfying regulators and reducing risk across AI-driven applications. The risks are growing more complex as attackers have learned to subvert the integrity of the ML supply chain by inserting malicious code into ML models that are widely shared by AI developers.
Case in point: RL researchers in February discovered a novel technique of distributing malware by abusing Pickle file serialization in ML models distributed across the highly popular Hugging Face platform. Even without a deep dive into ML-BOMs, their existence in a particular software stack will clue stakeholders into the fact that AI is present — something that is growing trickier by the day to identify, Petrillo said.
“The first step to adopting AI securely is to just know when you’re adopting AI. Part of the problem is we don’t even know the extent to which we’re using it.”
—Dan Petrillo
SaaSBOMs
Next in your essential visibility tools in the xBOM family, SaaSBOMs tackle transparency over services, RL's Petrillo said.
“We need to encompass all facets of software, and SaaSBOM is an interesting one because it acknowledges that software is more than just the bits and bytes of the package you build in. Software calls on services, touches endpoints, APIs, and so on. SaaSBOM brings visibility to that.”
—Dan Petrillo
The trick with SaaSBOMs is that they will constitute one of the most dynamic of all BOMs, because the services that the software calls to change so rapidly. This highlights one of the big challenges and opportunities of the xBOM: For most use cases, they aren’t meant to be static documents intended for human consumption.
Cyclone DX's Springett explained this in an episode of Nerding Out with Viktor.
“My SaaS BOM could change 50 times a day because maybe that's how many times I deployed to production. These are very, very dynamic things. So a file-based approach is not what you want. You actually want more of an API for these types of things.”
—Steve Springett
CBOMs
Cryptographic BOMS (CBOMs) stand as a third crucial xBOM component for extending the visibility over the software supply chain. CBOMs offer a clear and detailed look into the cryptographic assets used in a system, including algorithms, keys, and certificates.
This is essential for any application that depends on cryptographic elements, but it could especially be a game changer for crypto wallet and crypto exchange software, which has been heavily targeted by cybercriminals in recent years.
CBOMs highlight one of the advantages of xBOMs, being somewhat atomized from the broader SBOM, since a highly specialized cryptography team would likely be interested in ingesting just that specific set of data. At the same, time, though, xBOM data could just as easily be rolled into a single document or data stream, said Springett.
“You can have a BOM that has software and hardware and cryptography."
—Steve Springett
The future of the xBOM
The ML-BOM, SaaSBOM, and CBOM are just the tip of the iceberg for how xBOMs can extend software transparency. CycloneDX also supports OBOMs, HBOMs, and MBOMs, for operations, hardware, and manufacturing, among others. And there are more plans to extend in the future.
Springett recently mentioned working on an architectural BOM and blueprints for how applications are supposed to act, both of which could prove hugely helpful in making dynamic and very targeted operational decisions to mitigate threats before updates can be made to a particular piece of software.
Ultimately, the industry will have to evolve the BOM concept to something that is streamlined into the build pipeline — as well as any other software development telemetry or control, Springett said.
“In order for us to do this right, we are essentially going to need some kind of observability layer on top of our existing build infrastructure that automatically starts doing this stuff for us, not just a generation of the bills of materials, but in some cases accounting for the deficiencies in some of our infrastructure as well."
—Steve Springett
