What should be in an SBOM for cloud services?

Since the beginning of the NTIA Software Transparency Initiative, there was always an understanding (sometimes explicitly articulated in meetings) that, even though everyone knows that computing is moving more and more to the cloud, it was too early to start discussing what an SBOM for a cloud service should contain; first we needed to figure out what an SBOM for on premises (“on-prem”) software should contain.

When the NTIA Initiative ended last year and “moved” to CISA, there was general agreement that we needed to start thinking about SBOMs for cloud services. Thus, one of the five current CISA SBOM/VEX working groups is dedicated to that topic. I’ll admit that I wasn’t too excited about this topic, mainly because I thought we might end up having long discussions which in the end wouldn’t lead anywhere.

However, I’ve been surprised by how productive the group has been and how quickly we’ve come to a rough consensus (although it’s subject to change at any meeting) on what should be in an SBOM for cloud services (aka SaaSBOM, where SaaS means “software as a service”), even though we’re very far from writing a spec at this time. Here are what I believe to be the general points of our rough consensus (most of these were originally brought up by Steve Springett, the co-leader of the CycloneDX BOM format – which has supported SaaSBOMs for at least a couple of years):

First, a BOM – whatever flavor it is – needs to address the risks that are inherent to the environment in which it’s used, and specifically risks due to third parties. A software BOM is designed to address the risk that a vulnerability in a third party component of a software product running on an organization’s premises will be exploited by an attacker who will use this “foothold” to attack software and/or data found on the network, causing harm to the organization.

However, software running in the cloud doesn’t normally have a direct impact on the organization’s network (the exception brought up by one of the members of the SBOM Cloud working group is the case where an app might drop tainted JavaScript code on a user’s desktop). Therefore, it’s not very important that the user organization receive an SBOM listing the components of a cloud app that they use. This is for the better, since cloud apps are constantly changing. Because an SBOM needs to be re-issued whenever there’s been any change in the code of an app, the user would need to receive and analyze many SBOMs every day for the same cloud app; obviously, they couldn’t do their day job if they had to do this.

But it is important that the provider of the cloud service itself examines up-to-date SBOMs for whatever apps they offer in the cloud. The cloud service provider (CSP) should provide their customers an attestation describing various cybersecurity measures they’re taking, including generating and analyzing SBOMs for their apps.

Thus, a BOM distributed to users of a SaaS product doesn’t need to list actual software components, because they pose minimal risk to the user organization. What does pose a risk to the organization? Steve Springett pointed out early on that the main risk to the user organization from cloud software that they utilize runs through the third party services called out by the SaaS product.

What is the nature of this risk? Steve additionally pointed out that the risk to the organization, due to use of a SaaS product in the cloud, relates to data: both a) the risk that the organization’s data will be misused by a third party service called by the SaaS product, and b) the risk that false or misleading data will be provided by a third party service to the SaaS product, with some sort of deleterious consequences for the organization.

An example of a) is if a hospital would provide personal health information (PHI) to a third party app, but the third party would make it available to criminals who would sell the information. An example of b) is if a SaaS SCADA system for a natural gas pipeline system would be “informed” by a third party app that one of their lines was seriously underpressured, meaning they need to greatly increase pressure in the line; this might cause an explosion (this is somewhat like what happened in the San Bruno explosion in 2010, which caused eight deaths – although that wasn’t due to an online SCADA system, of course).

Given this, what should the SaaSBOM look like? It will obviously need to list every service that’s called out by the app itself (Steve Springett provided the workgroup this “services BOM” for Dependency-Track, the open source product he developed in 2010, which now is used over 250 million times a month to identify vulnerabilities for components listed in an SBOM. Dependency-Track isn’t SaaS, but this does illustrate what a BOM of services looks like. Of course, I’m sure Steve regularly makes SBOMs for D-T. In fact, both the software BOM and the services BOM are needed for any on-prem product that makes calls to external services).

However, just having a list of the services called out by a SaaS app doesn’t by itself help identify risks, any more than having an SBOM listing components in a software product by itself identifies risks. Just as vulnerabilities applicable to software components listed in an SBOM need to be identified in the NVD or another vulnerability database like OSS Index, so risks applicable to services need to be identified.

But how does a user identify services risks? Are there “service vulnerability databases”? I had never heard of one, but in yesterday’s workgroup meeting, someone posted exactly that in the chat. I’m sure there’s a lot that could be put into this database, especially regarding risks that aren’t exactly vulnerabilities. For example, I would argue that, if a service is operated out of North Korea, that in itself poses a risk, which could be included in this database as well.

My guess is that whatever the workgroup finally decides should be the format for a SaaSBOM (and that may not be the name for it, either. I’d be happy with “Cloud SBOM”) will include more than just a list of services. For example, Steve suggested that there should be a data flow diagram, listing what types of data (HTTP, PHI, etc.) flow into and out of the SaaS app. Obviously, that would also be important for an end user that wants to know what risks they face.

The bottom line is I’m now optimistic that there might be a SaaSBOM format available next year. What’s important now is to populate the Cloud Vulnerability Database (and similar databases, if any appear), so that, as SaaSBOMs appear, cloud users will be able to learn about the risks inherent in the cloud services that they use.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.