The case for a SaaS bill of materials

SaaSBOMs can provide greater visibility into the makeup of cloud-based software and infrastructure.

Note: This article originally appeared on CSO Online, and I co-authored it with Chris Hughes. It was what we believe to be the first use of the term “SaaSBOM.” Separately, and subsequent to the publication of this article, we learned that the CycloneDX SBOM format did in fact allow for the tracking of dependencies that are services rather than just stand-alone software components. That standard thus provides an actionable way to implement our recommendations.

President Biden’s cybersecurity Executive Order on Improving the Nation’s Cybersecurity has triggered massive buzz regarding software bills of material (SBOMs). While we advocate for improving software supply chain security through greater transparency regarding the components contained therein, the hype surrounding SBOMs needs direction to resolve a series of key implementation questions.

In addition to a lack of answers as to what consumers will do with SBOMs once they receive them, it is even less clear as to how to develop them for vendor-managed deployment models such as software as a service (SaaS). Especially as 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.

A SaaSBOM framework

To address this challenge, we propose a framework for what a SaaS bill of material (SaaSBOM) should look like. Explaining what such a document would comprise warrants a dedicated discussion because just agreeing on what exactly the “software” in question is for a given SaaS product is challenging. When receiving artifacts from a vendor, a customer planning to host them in-house can definitively know which items they have downloaded and track them accordingly. When consuming SaaS, such certainty is nearly impossible.

For example, does the “software” include cloud service provider infrastructure-as-a-service (IaaS) or platform-as-a-service (PaaS) offerings on top of which the product runs? What about tools like Ansible, Chef, and Terraform that the vendor uses to operate and maintain the deployment? The components of the product’s continuous integration/continuous delivery (CI/CD) pipeline accessible via single sign-on (SSO)? The human resources system that connects to the company’s identity provider facilitating said SSO capability? Even if a perfect accounting were possible, there are likely daily, if not minute-by-minute, changes in the environment of which the vendor—let alone the customer—would not be immediately aware.

In light of these uncertainties, we suggest that SaaS providers use each product offering they sell individually as the base unit of analysis. To build a SaaSBOM, a vendor would carefully analyze the technology stack upon which the confidentiality, integrity, and availability of data in said offering depend. The method for representing components hosted by the vendor itself is relatively straightforward and the existing software package data exchange (SPDX) or software identification (SWID) standards are appropriate for this task.

When the product relies on other SaaS, PaaS, or IaaS providers, however, providing those organizations’ bills of material as well could help to clarify the chain of dependencies. This would necessarily create a situation reminiscent of a Russian doll, where several SaaSBOMs (or PaaSBOMs or IaaSBOMs) might be nested within that for another product. Such a record could only include those components of the software supply chain of which vendors are aware and would likely miss several fourth-party dependencies. With that said, some sacrifice is unavoidable when building a workable model.

Building SBOMs from the customer perspective

Developing as comprehensive a picture as possible—separated logically by commercial offering—will allow vendors to build SaaSBOMs from their customers’ perspective. While there will certainly be room for interpretation—meaning that customers cannot reasonably demand contractual guarantees as to the SaaSBOM’s exact composition—some information along with clearly stated gaps is better than none.

Companies offering such detail will rightly be able to position it as facilitating effective technical due diligence, which provides more useful information than that from inferior vetting tools such as security questionnaires and external audits alone. Vendor information security teams will also likely appreciate a chance to take a full inventory of the systems their organizations are using, identifying and limiting shadow IT. Finally, the requirement to have a clear understanding of the interdependencies in the vendor’s network—and the incentive to minimize them to reduce SaaSBOM complexity—will have a beneficial side effect of encouraging segmentation and isolation of components, in line with zero-trust architectural principles.

Recording, tracking, and maintaining the voluminous and rapidly changing information in a SaaSBOM cries out for automation. Any effort dependent on manual accounting will likely fall apart quickly and developing machine-readable feeds for internal and external consumption should eventually become standard practice. Due to the inapplicability to SaaS of the SPDX or SWID frameworks, organizations such as the Cloud Security Alliance and Cloud Native Computing Foundation could greatly assist the community by driving the development of a new format encompassing the aforementioned considerations.

In the wake of state-sponsored attacks against corporate and government digital supply chains as well as infrastructure provider outages that have jolted the global economy, managing information risk posed by third parties will become increasingly critical. Especially with the increasing dominance of SaaS as a deployment model, developing a clear standard for SaaSBOMs is vital. Merely agreeing on how to scope such a document is the first step toward analyzing the risks posed by the various technologies and services that comprise modern software supply chains.

Reprinted with permission. © IDG Communications, Inc., 2021. All rights reserved.