6.6 SaaSBOM及API复杂度

为所包含的实体创建一个SBOM可能会很复杂，例如在本地交付的软件或容器映像。为具有云和SaaS等无数相互关系的动态且快速变化的环境创建SBOM可能是另一个级别的难度。

关于SaaS的SBOM的概念已经出现了讨论，它被称为SaaSBOM。云和SaaS引入了供应商管理的部署模型，而在这些模型中，消费者不拥有或控制底层的物理基础设施、托管环境、操作系统，甚至不是应用程序。应用程序仅仅是作为服务使用，即”as-a-Service“，而消费者对应用程序的配置和修改仅有有限的控制权。

一个更正式的定义是 NIST的800-145 Definition of Cloud Computing： ———————————————————————————————————————————————————— 提供给消费者的功能是使用运行在云基础设施上的提供商的应用程序。这些应用程序可以通过瘦客户机接口，如web浏览器（例如，基于web的电子邮件）从各种客户端设备或程序接口访问这些应用程序。消费者不管理或控制底层的云基础设施，包括网络、服务器、操作系统、存储，甚至是单个应用程序功能，可能有有限的用户特定的应用程序配置设置除外。 ————————————————————————————————————————————————————

2021年初，SBOMs快速流行起来，该行业的许多从业者开始提出疑问，是什么推动SBOMs在高度动态和复杂的环境中工作，比如SaaS（用于应用程序的另一种方法，不像传统的软件交付和消费）。这本书的作者之一在2021年9月共同发表了一篇题为《The Case for a SaaS Bill of Materials》的文章（www.csoonline.com/article/3632149/the-casefor-a-saas-bill-of-material.html）。正如文章所指出的，在SaaS环境中定义什么是软件是具有挑战性的。现代SaaS通常建立在现有的IaaS和PaaS环境上，这些环境通常由其他CSPs拥有。底层的IaaS和PaaS通常被定义为“as-code”，并包括物理组件和虚拟组件，所有这些组件都包括它们自己的软件。这在SaaS环境中定义软件时造成了一种复杂的情况，因为涉及到无数的代码和软件组件，以及包含的各种关系和所有权实体。也就是说，许多业内人士都是在服务和数据流的背景下，围绕着SaaSBOMs作为焦点。CISA的SBOM Working Group包括一个Cloud Working Group，那里的许多专业人士都主张采取这个立场。Cloud Security Alliance（CSA）的出版物《SaaS Governance Best Practices for Cloud Customers》也引用了在SaaS中使用SBOMs，本书的其中一位作者领导了该出版物（https://cloudsecurityalliance.org/artifacts/saas-governance-best-practices-for-cloud-customers）。

为了进一步增加挑战，供应商经常使用工具来维护和操作底层云环境以及驻留在它们之上的SaaS。其中最值得注意的是 Ansible、Chef和Terraform，所有这些都有助于配置、部署和管理SaaS所依赖的云基础设施。当然，为了促进SaaS的交付，还涉及到其他的系统和软件，如CI/CD管道和IAM软件。

所有这些实体都是由软件组成的，并且经常动态和快速地变化，这使得定义它们确切的软件组件组成具有挑战性。建议的方法包括让SaaS供应商在他们的控制范围内尽可能确定整个技术组件，SaaS应用程序依赖这些组件能够向应用程序消费者提供SaaSBOM。尽管具有挑战性，但这种方法仍具有可能性，因为SaaS提供商至少应该能够访问并在其直接控制下理解应用程序交付中使用的组件。

正如我们所提到的，这并不能解决向SaaS应用程序消费者提供底层IaaS和PaaS提供商的软件和系统的详细SBOM的挑战，所有这些都是SaaS应用程序的关键依赖关系。

CycloneDX SaaSBOM

我们并不是唯一认识到SBOM采用性和成熟度是具有挑战性的人。作为行业领先的SBOM格式之一的CycloneDX，它是一个由 Open Worldwide Application Security Project (OWASP)管理的项目，已经提出了SaaSBOM模型，如图6.5所示。

CycloneDX SaaSBOM信息认识到，现代软件依赖于许多外部服务，甚至可以完全由服务组成。出于这个原因，他们致力于使CycloneDX能够代表各种服务类型，包括微服务、FaaS、systems of systems（SoS），当然还有SaaS。CycloneDX指出，SaaSBOMs可以作为infrastructure-as-code (IaC)的补充，IaC还提供了复杂系统的逻辑表示。在IaC的情况下，这包括云架构组件，如网络、计算和访问控制，所有这些都在一个as-code模型中定义。

CycloneDX指出，SaaSBOMs可以提供类似的逻辑表示，包括所有服务、服务依赖关系、相关的URL，甚至是服务和系统之间的数据方向流。

如前所述，SaaS由每个体系结构中的一组独立的应用程序和服务组成，用于向消费者交付应用程序。CycloneDX的SaaSBOM功能允许将服务和软件组件库存成单个BOM或独立的BOMs。CycloneDX建议将大型系统的SaaSBOMs与SBOM脱钩，因为云和SaaS涉及动态服务和部署场景。SaaSBOM可以表示为一个单一实体，其中有许多与之关联的SBOMs，SBOMs表示协同交付SaaS应用程序的相关服务。

因为每个独立的服务显然都有自己独特的漏洞，所以CycloneDX还支持来自其他系统和BOMs的BOM中的能力引用组件、服务和漏洞。这被称为BOM-Link（https://cyclonedx.org/capabilities/bomlink），它支持两种通用场景，即从另一个BOM引用一个BOM，并从一个BOM到另一个BOM引用一个特定的组件或服务。

CycloneDX还建议解耦Vulnerability Exploitability eXchange（VEX）和BOMs，因为BOM可能直到系统清单完成后才能更改，但VEX可以更频繁地更改，因为可能出现与现有和正在使用的软件组件相关的新漏洞。

工具和新兴讨论

从我们的讨论中可以明显看出，实现一个SaaSBOM，或者是一个普通的SBOM，因为它与云的复杂和动态的世界有关，并不是一件容易的事。它将不可避免地需要新的流程和工具来促进它的广泛采用，因为人类要跟上软件组件库存和相关漏洞的快速变化速度是不现实的。

因此，越来越多的人呼吁进一步讨论工具和功能的主题，以帮助解决针对SBOMs的云和SaaS环境中的这些差距。2022年7月，CISA就几个主题举行了一系列的会议，其中包括“Cloud & Online Applications”（www.federalregister .gov/documents/2022/06/01/2022-11733/public-listening-sessions-onadvancing-sbom-technology-processes-and-practices）。这些事件并不是为了寻求共识，但这些对话被用来促进关于SaaS和云应用程序的SBOMs主题的公开对话。

此外，Department of Homeland Security (DHS) Science & Technology (S&T) Directorate正在鼓励技术公司帮助开发自动化的SBOM工具。这是由于DHS S&T意识到大规模管理SBOMs的复杂性，包括SaaS。在他们的声明中，S&T承认，试图利用软件漏洞的攻击可能会导致安全和社会所依赖的关键系统的中断和损害。有关更多信息，请参见“DHS S&T Seeks Solutions to Software Vulnerabilities”：

https://dhs.gov/science-and-technology/news/2022/07/11/st-seeks-solutions-software-vulnerabilities