Software bills of materials (SBOMs) have become a hot topic recently — for a number of reasons. High-profile attacks on software supply chains have exposed the need for organizations to know what third-party and open-source components are in the applications they use. SBOMs are seen as an essential first step on that journey.
Further momentum is being stoked by the private sector and government initiatives, such as the SBOMs Everywhere program that's part of the Open Source Software Security Mobilization Plan announced in May by the Linux Foundation's OpenSSF, as well as President Biden's Executive Order on Improving the Nation's Cybersecurity.
However, because the push for SBOMs is still in early days, questions abound. One of them is how can SBOMs be developed for vendor-managed deployment models, such as software as a service (SaaS)? That is a significant question that may influence SBOM adoption. "[A]s the industry sprints toward nearly ubiquitous use of SaaS, this ambiguity presents a hurdle toward the effective use of SBOMs as a risk management tool," warned Walter H. Haydock and Chris Hughes, writing for CSO Online.
Tobias Whitney, vice president for strategy and policy at Fortress Information Security, a supply chain threat protection company, said that one way to leap the SaaS hurdle is through a SaaSBOM.
"A SaaSBOM addresses some of the off-premise concerns that may not be clear in a traditional SBOM. We're taking the concept of software and recognizing that an application operating in the cloud might have different threat vectors associated with it, different vulnerabilities that can lead to cascading risks to the purchasing organization."
—Tobias Whitney
While an SBOM informs a customer about all the components used in a software program, the SaaSBOM focuses much more on services, said Dennis Zimmer, co-founder and CTO of Codenotary.
"The reason for that is software as a service is more than software that runs somewhere in the cloud. It is a complex mix of infrastructure, software components, service endpoints and last but not least, the data flow between the services behind the publicly accessible URL."
—Dennis Zimmer
Here are five reasons why your organization should consider a SaaSBOM — plus insights into the challenges facing implementation of SaaSBOMs.
[ Get White Paper: Go Beyond the SBOM. Plus: Join Webinar, Welcome CycloneDX xBOM ]
1. SaaSBOMs provide fresh information about apps running in the cloud
There are a few open questions in the industry on how you make SBOMs work for cloud services "where the dynamic and elastic nature of the cloud means resources are being consumed and changed on a more frequent basis," said Charlie Jones, software supply chain security product manager at ReversingLabs.
"As a result, the software bill of materials that you're creating for cloud-native software is only a point-in-time view of what makes it up. Because the information is changed so often, it becomes stale and out-of-date quickly."
—Charlie Jones
2. SaaSBOMs make service components more transparent to users
Just like an SBOM attempts to make transparent all of the dependencies within a given piece of software, a SaaSBOM extends this concept to software as a service to provide an artifact that lists all of the various technology substrate components that go into offering a given SaaS, explained Ed Moyle, systems and software security director for Drake Software, and a member of the ISACA Emerging Trends Working Group.
"There is a whole ecosystem of players involved in delivering a cloud service that is currently opaque to cloud customers."
—Ed Moyle
As an example, Moyle said to consider a SaaS that runs on Apache, stores data in MariaDB, and uses PaaS components from AWS for business logic. To give full transparency, you'd need to know all of the elements that go into the SaaS software itself including sub-dependencies, "but then you'd also need to know the various dependencies that go into each of the individual elements involved in delivering that code to production—the dependencies for Apache, MariaDB, and then, in turn, the dependencies used by Amazon in delivering AWS Lambda," Moyle said.
3. SaaSBOMs help teams understand all dependencies — not just libraries
Jeff Williams, CTO and co-founder of Contrast Security, explained that a SaaSBOM allows you to model the APIs, services, and other connections that modern apps make.
"These are remote dependencies and just as important to security as local dependencies. Your SaaSBOM will probably have references to all the software in these remote dependencies, which can also have both local and remote dependencies."
—Jeff Williams
Unlike an SBOM, which focuses on the components of a piece of software, a SaaSBOM includes infrastructure and data flow information, such as logical representation of a system, inventory of all services, reliance on other services, endpoint URLs, data classifications, and directional flow of data between services.
4. SaaSBOMs add another level of software security assurance for vendors
When organizations provide SaaS or PaaS services to internal or external customers, the consuming customer needs to trust that all is done well. Now that trust is primarily based on third-party certification and brand name.
"Given the increase of data leaks, software supply chain attacks and ransomware attacks, the customer deserves more information about the infrastructure, components, data storage and data flow of a service used. Providing a SaaSBOM to the consumer of the software massively enhances trust and transparency. It also allows consumers to check the level of security the SaaS service provider maintains."
—Dennis Zimmer
5. SaaSBOMs will become a requirement in the software industry
Biden's Executive Order already requires vendors to have SBOMs in place when they want to sell to the U.S. government, starting in 2023. Many companies are going to follow suit and have the same requirement, Zimmer noted.
"That means any SaaS or PaaS needs to provide SBOMs as well and the next logical step will be the SaaSBOM to cover the data flow and infrastructure behind that service. So, there is no doubt that the SaaSBOM will be an important topic in the coming years."
—Dennis Zimmer
Williams said that services are just a different kind of dependency, but they're just as critical to security. "And almost every kind of software makes service connections. So I believe SaaSBOM will be the only kind of SBOM in the very near future," he said.
Can SaaSBOMS keep up with the pace of SaaS?
There are those, however, who believe SaaSBOM proliferation faces stiff headwinds. The frequency at which components change in a SaaSBOM is a challenge and might even change from customer to customer.
"Because of these challenges, and a few other nuances, I believe that the delivery of SaaSBOMs will trail traditional product BOMs by some time, although there may be intermediate steps—starting with simply enumerating the SaaS services used," maintained Ken Arora, a cybersecurity engineer and architect at F5, a multi-cloud application services and security company.
SaaSBOM questions that need answers
Jones noted that some questions need to be answered before software publishers take on the massive engineering overhead needed to maintain SaaSBOMs.
"We need to answer questions such as at what frequency do SaaSBOMs need to be generated and shared, what depth should they go to — components and services, or just services — and how unique does it need to be. Can it just apply to out-of-box services or does to have to be unique to each customer?"
—Charlie Jones
One of the challenges facing organizations that receive an SBOM is what to do with it, Moyle observed. "I think SaaSBOMs will have this same challenge," he continued.
"More broadly. I think this has the added challenge that it fights against why people find the cloud compelling. It deliberately abstracts the end user away from the minutiae of the underlying tech stack. By asking for transparency into the details of how the service is delivered, it means you now have to become educated on each of those components to understand and use the artifact productively."
—Ed Moyle
Larry Maccherone, DevSecOps transformation evangelist for Contrast Security, said that the value of a SaaSBOM ultimately may lie less with what a customer does with it than what the software development organization learns by creating it.
"SBOMs are in the news now because there is a requirement that they be shared when the U.S. government is the consumer of the software. However, there is no requirement that anyone do anything useful with that SBOM once it is shared."
—Larry Maccherone
Maccherone said the path to enabling that sense-making is very cloudy. He said SaaSBOMs were likely to die in the "trough of dissolution" — a reference to Gartner’s hype cycle — for on-premise software SBOMs. "The difficulties for SaaSBOMs are another order of magnitude larger," he said.
But Maccherone still holds hope, noting, "I’m still cautiously enthusiastic about SBOMs and SaaSBOMs, not because the sharing of that data is likely to be useful to the organization receiving it, but rather, because it will cause the producers to think harder about what they put in their software knowing that they must publish those contents."
"This is exactly what happened with the food labeling standards. Food vendors started producing more food that was healthier. SaaSBOM could have a similar effect."
—Larry Maccherone
The rise of CycloneDX's xBOM
The SBOM has been fully supported by the OWASP Foundation’s CycloneDx, an industry-recognized standard for machine-readable SBOMs. And in 2023, CycloneDx introduced the Extended Bill of Materials (xBOM) to address the full stack bill of materials, adding 11 other bills of materials (BOMs) for areas that span software as a service, cryptography, hardware, manufacturing and other technology ecosystems. In its most current form, CycloneDX v1.6 was ratified as an Ecma International standard, providing a global xBOM specification for use across multiple domains.
The xBOM is a full-stack BOM standard that provides advanced supply chain capabilities for cyber risk reduction, and includes 12 different BOMs spanning the software and hardware ecosystems — including the SaaSBOM. The xBOM builds upon the traditional elements of an SBOM to provide a more comprehensive view by including a broader range of components and information related to software-based products.
The 12 BOMs include:
SBOM (Software Bill of Materials)
An SBOM is a complete, machine-readable inventory of software components, including metadata, dependencies, and licenses, providing transparency across the software supply chain.
SaaSBOM (Software as a Service Bill of Materials)
SaaSBOM identifies and inventories cloud-based applications, APIs, endpoints, and data flows to help ensure governance, compliance, and risk mitigation in SaaS environments.
CBOM (Cryptography Bill of Materials)
A CBOM lists cryptographic assets such as keys, algorithms, and libraries to evaluate crypto agility, policy compliance, and potential vulnerabilities in cryptographic implementations.
ML-BOM (Machine Learning Bill of Materials)
ML-BOM provides transparency into machine learning systems by documenting models, datasets, parameters, training processes, and dependencies – enabling better governance and trust in AI development.
BOV (Bill of Vulnerabilities)
BOV enables structured sharing of vulnerability data affecting software components, supporting automated analysis, coordination, and remediation across the software ecosystem and threat intelligence systems.
VDR (Vulnerability Disclosure Report)
The Vulnerability Disclosure Report (VDR) standardizes how known vulnerabilities are communicated, enhancing collaboration between suppliers, researchers, and consumers during coordinated vulnerability disclosure processes.
VEX (Vulnerability Exploitability eXchange)
VEX communicates the exploitability of a vulnerability in a specific context, helping organizations prioritize remediation based on actual exposure, not just CVE presence.
CRNF (Common Release Notes Format)
This format standardizes software release notes, allowing automated systems to interpret changes, improvements, and fixes in a structured, machine-readable and developer-friendly format.
CDXA (CycloneDX Attestations)
CDXA provides cryptographically verifiable, machine-readable proof of build integrity, policy compliance, and artifact provenance to support secure software development and delivery.
HBOM (Hardware Bill of Materials)
HBOM inventories hardware components, firmware, and associated metadata, ensuring security, compliance, and lifecycle management of embedded systems and connected IoT hardware devices. Items are related to, but not contained within software.
OBOM (Operation Bill of Materials)
OBOM captures operational configurations, environments, and runtime dependencies that impact system behavior, helping to manage post-deployment risk and ensuring secure and consistent software execution. Items are related to, but not contained within software.
MBOM (Manufacturing Bill of Materials)
MBOM outlines the manufacturing and assembly details of software, services, and hardware to ensure traceability, quality assurance, and regulatory compliance throughout the production process. Items are related to, but not contained within software.
Going Beyond the SBOM and xBOM
The xBOM put forth by CycloneDX v1.6 addresses the nature of how various assets move through and are incorporated into software supply chains. Industry guidelines and regulations are increasingly calling for the SBOM – and now the xBOM – to bring detailed visibility into their software ecosystems by representing comprehensive inventories of software components, dependencies, and relationships. Spectra Assure supports these standards, and the insights they bring.
While these insights are essential, they alone do not bring visibility into malware, tampering, or other exploits that impact software development and their pipelines. Learn how Spectra Assure goes beyond the SBOM/xBOM.
