如何在 SDLC 中使用SBOM

今天，我们看到更多的企业开始优先使用软件材料清单(SBOM)。但是对于许多人来说，SBOM 主要是作为一个可选项生成的，在SDLC全流程中很难看到作用。

这就错过了在整个软件开发生命周期(SDLC)中集成 SBOM 的重要机会。通过正确的步骤，组织可以利用 SBOM 数据来理解和管理各种风险，包括软件供应链安全性和开源许可证遵从性。

本文中，我将介绍我们在UniSCA中看到的帮助组织使用 SBOM 在整个软件开发生命周期中管理风险的工具、过程和策略。

计划阶段的 SBOM

软件开发生命周期的计划和定义阶段是产品和工程团队一起决定下一个版本的软件: 特性、特性定义和接受标准。这也是确保您拥有适合您的产品的 SBOM 工具的好时机。

目前市场上有许多 SBOM 工具，其中许多工具非常善于支持 SBOM 生命周期的特定部分。很难找到一种解决方案，可以满足您提出和使用第一方和第三方 SBOM 数据以及获得真正的安全好处的所有需要。

我们的目标是找到一些工具，使您能够最大限度地、几乎是机械地覆盖您所使用的语言和技术。我所说的机械是指，如果您必须以一种方式为特定的生态系统或语言创建 SBOM，而以另一种方式为另一种语言或生态系统创建 SBOM，那么您将得到不一致且可能不准确的结果。

我还要指出，今天的 SBOM 讨论主要集中在第一方软件——您和您的组织正在创建的软件。但是，软件供应链的本质是，您也使用了许多其他公司正在开发的软件。因此，我们看到越来越多的组织优先考虑能够将第三方 SBOM 导入到系统中的工具，在这种系统中，您可以理解并管理许可证遵从性和安全性。

其他工具考虑因素包括:

您想使用哪些 SBOM 格式和规范，例如 SDPX 或 CycloneDX？
您希望如何交付 SBOM？您是否希望将 SBOM 作为构建过程的一部分签入源代码？或者当一个实际的交付工件或释放出去的时候包括它？

最终，您对这些问题的回答将大大有助于帮助您确定满足组织需求的最佳 SBOM 工具。

设计和构建阶段的 SBOM

在设计和构建阶段，我们真正看到产品和工程涉众一起工作，以确保在开发软件时，您了解与使用某些组件相关的风险。

问题的关键在于，如果你花了六个月的时间构建一个依赖于某种开源依赖的组件，但后来发现存在一个关键的漏洞或许可风险，使得它无法使用该组件。对每次提交进行这种检查可以确保您有一个快速的反馈周期，以便在过程的更早阶段改变、替换或考虑其他选项。

这是我们建议在构建过程中生成 SBOM 的一个重要原因。如果您在构建完成后立即运行 SBOM 报告，那么在解析这些依赖项时，您将获得最准确、最新的依赖项列表。

一旦有了依赖项列表，就可以开始分析它们了。这就是像 FOSSA 这样的工具非常有用的地方。FOSSA 提供了许多不同类型的依赖元数据，我们根据对 SBOM 数据的分析标记了许可问题和安全漏洞问题。

部署和测试阶段的 SBOM

您已经设置了 SBOM 程序，生成了一个最新的依赖项列表，并标记了安全和许可问题。现在，是激活进程门的时候了，这个进程门将防止出现严重漏洞或许可证遵从风险的发货软件。

这些流程大门通常是法律、安全和工程涉众之间就以下主题进行对话的结果:

我们是否应该允许在给定的产品中使用有版权许可的组件? 该产品是如何分发的？
如果存在安全漏洞，而且每个生产的软件都有漏洞，我们现在需要解决哪些问题？我们可以把哪个留到下一个版本？

使用UniSCA这样的工具来实现这些流程是最简单的，它允许组织自动化实现。例如，如果您的法律和工程团队已经同意某个 SaaS 产品不能使用任何 AGPL 许可的代码，UniSCA可以自动标记该问题并使 CI 构建失败，直到您替换了 AGPL 组件。

这就是 SBOM 能够提供最大价值的地方——您知道软件中的内容以及这些组件带来的风险，因此您可以采取适当的行动来实现组织实现的 SLA。鉴于现代应用程序可能有数百个开放源码依赖项，使用自动化来快速找到这个大海捞针中风险最大的那个是至关重要的。

这个过程同样适用于第三方应用程序 SBOM: 一年多以前，许多组织正在处理 Log4Shell 漏洞，并急切地试图确定这些应用程序是否(以及在哪里)正在使用 Log4J。支持导入第三方 SBOM 的工具可以让你像分析我们自己的代码一样分析这些 SBOM，并且在遇到像 Log4Shell 这样的关键安全漏洞时，立即采取行动，包括提醒供应商升级到安全版本。