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, a software supply chain security provider.
"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 a free SBOM and supply chain risk analysis report ]
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, a software security assurance evangelist 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
