Should companies ask for a SaaS software bill of materials?

SaaS SBOMs benefit the providers

SaaS shifts some operational responsibility from the customer to the software supplier. For example, keeping the OS patched and securing the underlying infrastructure are the cloud service provider's responsibility, not the customer's.

In terms of updating SaaS applications, the supplier is also responsible, not the customer. The provider maintains the software and its supporting dependencies, as well as maintains the underlying stack upon which the application rests.

Since a key benefit of using an SBOM is to help organizations identify out-of-date, at-risk or otherwise problematic dependencies that require action to be taken, the main value proposition of a SaaS SBOM would be to the supplier instead of the customer.

It turns out, though, that this is not the only way in which an SBOM can provide value.

SaaS SBOMs can still be useful for customers, too

SBOMs can still be valuable for SaaS customers even though the entity directly responsible for addressing software dependency issues and/or stale dependency components is the provider.

First, SaaS can be complicated. Sometimes, the browser-facing portion of a SaaS platform is a small subset of what it does. Take any communication platform as an example, such as Slack, Teams or Zoom. It can be accessed through the website, as well as a desktop app, mobile app, browser plugin, mail-client plugin and numerous other methods.

Based on risk profile, business context or organization-specific needs, companies might have to track vulnerabilities or other issues in those other vehicles -- e.g., mobile software, thick clients, plugins, etc. In these cases, while access to the SaaS platform is via the web and while the support work for addressing security issues is done externally to an organization, it can be advantageous to keep tabs on how vulnerable these components might be since they can be a launchpad for attacks into the organization.

Also, keep in mind that many SaaS offerings provide ways for third parties to interface with the product via APIs, plugins and other modules, often offered through an application marketplace that facilitates and encourages third-party code. These can be written by in-house developers or external organizations. Security teams might want to track the dependencies, vulnerabilities or other facets of these third-party components. One way to facilitate this is using an SBOM.

Finally, compliance requirements may mandate companies track composition in a SaaS platform, regardless of mechanism of access. Customer contractual requirements or other regulatory compliance might require companies to maintain an SBOM for certain processes or applications.

Compelling reasons exist to consider asking for SaaS composition information, as well as to track that information -- even in situations where service providers address issues such as vulnerable or stale dependencies.

It may not yet be a common request of SaaS providers, but if more customers request SBOMs, providers will be more likely to have one prepared. Make asking for an SBOM a normative experience to build up pressure on providers to create one.