在过去的几年中，人们越来越意识到在软件中使用开源组件的固有风险。考虑到大多数软件都是开源和专有逻辑的混合体，了解直接或暂时从外部导入哪些成分对于最终软件产品的正确风险管理至关重要。由于使用复杂的电子表格跟踪成分的日子早已一去不复返了，而且启动效率极低，因此完成此类跟踪的主要方法是使用 SBOM（一种软件物料清单）。与其他物料清单一样，它本质上是构建软件的软件成分列表，添加了不同成分之间的关系，特别关注哪些组件相互依赖。
当今市场上使用两种主要的 SBOM 格式：SPDX 和 CycloneDX。
软件包数据交换（SPDX） 是 Linux 基金会的一个开源、机器可读的 SBOM 项目。最新版本的 SPDX 的设计符合 NTIA 的标准：软件物料清单的最小元素.'它列出了软件的组件、版权、许可证和安全参考。
旋风DX (CDX) 也是由开放 Web 应用程序安全项目 (OWASP) 社区开发的开源且机器可读的 SBOM 格式。作为一种 BOM 格式，CycloneDX 除了准备软件物料清单之外还有其他应用。它还可以用于编译硬件和云系统的组件、漏洞和服务。
为什么 SBOM 很重要？
SBOM 对于软件开发团队、采购组织和最终用户非常有用。使用它可以帮助保证开源和第三方组件是最新的，并提供对哪些项目依赖项存在可能在您的软件中可利用的已知漏洞的可见性。另一方面，软件购买者可以利用 SBOM 通过漏洞评估来分析产品固有的风险。
通过与供应商合作，确保他们能够访问有关实施到系统和/或产品中的项目组件的正确且最新的信息，可以更好地为组织提供服务。他们还应该定期评估其 SBOM，以帮助最大限度地降低使用开源和第三方组件的风险。
SBOM样本
根据您使用的 SBOM 格式，SBOM 的组件可能会有所不同。根据项目的大小和复杂性，SBOM JSON 文件可以轻松达到数千行或更多。由于查看一千行文件并不能提供太多信息，因此让我们使用现有的、更简单的示例来了解每种 SBOM 格式包含哪些内容。我们将仔细研究当今市场上两种主要格式的样本。
SPDX
我们将要关注的 SPDX SBOM 示例可以找到 点击这里.
JSON 以有关文件本身的一般信息（元数据）开始。
之后，我们获得有关我们正在检查的软件的元数据：
注意校验和及其值。 SBOM 的每个部分都包含相关部分的加密和结果，以便检查文件的人员可以确保提到的软件或组件与他们正在查看的软件或组件相同。
如果没有这种保证，您可以轻松找到具有相同名称的组件或软件的多个副本，并且您不知道这些版本中的哪个版本已被检查或包含在软件或描述它的 SBOM 中。
根据检查的软件的描述，我们可以开始查看组件：
您可以看到包含多个字段来描述组件的许可证、其主页、版本、全名等。
您可以在 SPDX 格式中找到的另一件事是注释 - 稍后对某个部分进行的添加，包括更多信息，有时甚至是自由文本：
要了解有关此格式及其功能的更多信息，您可以访问 SPDX页面 Linux 基金会的成员。
旋风DX
CycloneDX SBOM 格式可以在 JSON 文件、XML 文件或协议缓冲区中描述。为了使事情变得均匀和简单，我们将遵循一个简化的 CycloneDX JSON 示例。描述的例子可以找到 点击这里.
JSON 以有关文件的一般元数据信息开始。
然后检查软件上的元数据：
之后是软件组件及其依赖项：
请记住，这是一个简化的示例，格式可能包含许多其他信息。要更全面地了解各种用例，您可以查看 OWASP CyclonDX 用例页面 点击这里.
以下是该页面中的一个示例，演示了依赖项列表的构建：
下面是来自 OWASP 的对该格式的各个组件的更广泛的描述 物料清单能力 页面：
如何使用 SBOM
如果您无法按照此处看到的文件示例进行操作，请不要感到难过。尽管 JSON 文件非常适合人类阅读，但它们更适合机器可读，以便专用软件可以提取信息并输出分析提供的结果。
您可以使用软件组件列表来检查它是否包含不需要的开源许可证（GPL3.0 或 MPL1.1 行）。您可以定期检查依赖项列表以查看是否有任何可用更新，或者根据漏洞数据库检查软件包名称以了解您的软件包含哪些有问题的依赖项。
获取 SBOM 并取回所有信息可能听起来很复杂，但请记住，您不必自己完成这一切。像 Scribe Security 平台这样的服务可以消除很多麻烦并提供更多好处。请随意查看我们的平台，看看您还可以如何使用我们对您的开发生命周期和最终产品的持续监控系统来管理风险。