技术文章

使用本指南可快速了解软件物料清单 (SBOM) 以及如何在构建管道中使用它们。Sonatype Lifecycle 支持 CycloneDX 和 SDPX 格式。

概述

如果您在这里，您可能听到了有关要求供应商为软件供应链提供 SBOM 安全性的行政命令的讨论。这是个好消息！自成立以来，自动化开源风险的识别和管理一直是我们的重点。我们是 SBOM 标准的早期采用者，具有许多关键特性：

• Sonatype 积极参与 CycloneDX SBOM 规范和开发。

• Sonatype Lifecycle 支持使用我们的 CLI、API 和 UI 扫描 SBOM。

• Sonatype Lifecycle 可以以 CycloneDX 或 SDPX 格式导出任何应用程序扫描报告。

旋风DX

CycloneDX 是报告和跟踪应用程序中使用的所有开源依赖项的绝佳标准。它既包括组件的哈希指纹，也包括packageUrl确定组件来自何处的哈希指纹。最近，该标准开始包含基本的漏洞数据以及组件详细信息，以了解风险，这既有好处也有坏处。这可能会给我们带来当时已知的安全风险，但是，这可能会给我们一种错误的安全感，因为在生成 SBOM 后会发现新的漏洞。 

SPDX

软件包数据交换 (SPDX) 是另一种用于通信软件物料清单信息的开放标准，它擅长捕获许可证信息并将其自身定位为 CycloneDX 的替代方案。 

SBOM 用例

所以问题是，我们该如何处理它们？

以下是 Sonatype 客户使用 SBOM 的三个主要用例：

1. 消耗 SBOM

2. 生成 SBOM

3. 管理 SBOM

消耗 SBOM

Sonatype Lifecycle 可以将 SBOM 作为应用程序分析的一部分进行扫描，或者在独立的 SBOM 上运行扫描。 

分析阶段

Sonatype 分析分为三个阶段：

1. 分析构建过程中进入应用程序的所有组件

2. 收集所发现组件的身份和漏洞数据

3. 并将该数据与您的治理政策进行比较以生成报告

在构建期间包含带有分析的 SBOM

在某些情况下，使用 SBOM 进行分析可能比单独扫描构建工件产生更好的结果。这是因为我们不仅可以报告应用程序中找到的所有内容，还可以更明确地报告这些部分的来源。SBOM 提供了应用程序构建方式的谱系，该谱系未包含在最终应用程序中。对于使用部分组件而不是整个组件的生态系统尤其如此。同样，我们可以更好地确定用于许多组件共享的公共部分的最终源组件。当许可证等元数据仅与组件而不是其部件相关联时，这一点至关重要。

在构建应用程序之前分析 SBOM

一项挑战是您不能总是在构建过程中进行分析。应用程序的构建方式不会与最终工件一起存储。尝试在构建之前或之后扫描应用程序可能会导致混乱或不完整的结果。Sonatype 解决了这个问题，允许您在分析中使用或包含 SBOM，以将组件的谱系包含在扫描结果中。这使您可以随时使用 SBOM 对应用程序进行分析。

以下是一些值得考虑的用例：

• 通过分析主动开发中的源代码清单来向左移动，以便在过于依赖新的开源组件之前了解风险。 

• 将应用程序推广到生产环境时，请检查是否发现任何新的违规行为或执行更严格的发布政策。

• 将 SBOM 的时间点副本与二进制文件一起保存在存储库中，或者保存在安全的中央存储库中，您可以在需要时快速访问它们。

SBOM 最佳实践

• 构建应用程序时，生成并存储 SBOM 以及打包的二进制文件，以便您始终准确地了解最终应用程序中的内容

• 在部署之前使用 SBOM 分析您的应用程序，以防止关键漏洞进入生产环境

• 与主要利益相关者分享您的 SBOM，但您可能希望避免公开它们

Sonatype Lifecycle 扫描仪和 UI 期望 SBOM 具有特定的命名格式，以便扫描仪将文件识别为 SBOM。扫描 SBOM 时请使用以下命名格式，否则扫描将忽略该文件。前缀和第一个破折号是可选的，您需要相应地使用正确的文件类型。该前缀用作任何未知组件的身份源。

[前缀]-bom.[xml|json]

请参阅下面的扫描前生成 CycloneDX SBOM，以创建 SBOM 以包含在您的 Sonatype 评估中。

使用 CLI 扫描 SBOM

• 查看有关使用 CLI 通过命令行扫描程序扫描应用程序的CLI 文档。

• 直接按照上述命名要求的格式定位您的 SBOM，或者在构建期间将 SBOM 与应用程序的其余部分一起包含在扫描上下文的根目录中。 

• 查看CycloneDX 应用程序分析和SPDX 应用程序分析 页面，了解有关扫描 SBOM 的更多详细信息。 

使用 API 扫描 SBOM

SBOM 也可以直接使用第三方 REST API上传。

1. REST 调用的示例，包括将 SBOM 作为调用的数据目标 (-d)。

1. 我们使用“cyclonedx”作为源参数来识别 sbom 的来源（“spdx”可用于 SPDX 内容扫描的源参数）。

2. 或者，在标头中使用“application/json”来上传 JSON 文件。 

   卷曲-u {用户}：{密码} -X POST -H“内容类型：application/xml”-d'{bom_text}''http://localhost:8070/api/v2/scan/applications/{applicationid }/来源/cyclonedx'- u {用户}：{密码} - X POST - H “内容类型：application/xml” - d '{bom_text}' 'http://localhost:8070/api/v2/scan/applications/{applicationid} /来源/cyclonedx'

2. 返回 statusUrl 以监视结果。 

1. 重复调用 statusUrl，直到结果准备就绪。

2. 分析通常需要大约 20 秒才能返回报告，而大型项目则需要几分钟。

   {“statusUrl”：“api/v2/scan/applications/{applicationId}/status/{statusId}”}“statusUrl” ：“api/v2/scan/applications/{applicationId}/status/{statusId}” }

3. 扫描的详细信息将与策略操作和 { reportHtmlUrl } 一起返回，您可以在其中找到完整的结果。 

扫描 UI 中的 SBOM

您可以使用 UI 扫描应用程序的 SBOM。

1. 导航到“组织和策略”选项卡并找到要扫描的应用程序（如果不存在，您可能需要添加它）

2. 在右上角的“操作”下，选择“评估文件”选项。

3. 从选择文件选项中，找到满足上述命名要求的 SBOM，选择一个阶段，然后选择“上传”按钮。

4. 选择查看报告。

sonatype.com/iqserver/files/137202836/137202838/1/1668529595311/image2022-11-10_14-46-28.png" height="250" style="box-sizing: inherit; margin: 0px; padding: 0px; border: 0px; height: auto;"/>

生成 SBOM

无论您是致力于遵守行政命令还是需要标准方法来报告依赖性数据，使用 Sonatype 工具创建 SBOM 都很容易。Sonatype 工具生成的 SBOM 符合 NIST 报告的所需标准。

每个 Sonatype 扫描报告都可以导出为 XML 文件或 JSON 文件格式的 CycloneDX 或 SPDX SBOM。您可以在扫描报告的 UI 中执行此操作，也可以通过 REST API 以编程方式执行此操作。

通过 UI 导出 SBOM

通过 UI 获取 SBOM。 

1. 导航至最新的应用程序扫描报告

2. 从选项菜单中选择：

1. 导出 CycloneDx - CycloneDx SBOM 以 XML 文件形式下载

2. 导出 SPDX -165 新品SPDX SBOM 以 JSON 文件形式下载

sonatype.com/iqserver/files/137202836/171671793/1/1689688843463/export-sbom.png" height="250" style="box-sizing: inherit; margin: 0px; padding: 0px; border: 0px; height: auto;"/>

通过 REST API 导出 SBOM

获取 CycloneDx SBOM 的示例。查看有关IQ Server 的 CycloneDX REST API的文档。 

curl -u admin:admin123 -X GET -H '接受：application/xml' -o 'bom.xml' 'http://localhost:8070/api/v2/cycloneDx/1.4/{applicationInternalId}/stages/build'- u admin : admin123 - X GET - H '接受：application/xml' - o 'bom.xml' 'http://localhost:8070/api/v2/cycloneDx/1.4/{applicationInternalId}/stages/build'

获取 SPDX SBOM 的示例。查看有关IQ Server 的 SPDX REST API的文档。

curl -u admin:admin123 -X GET -o 'spdx.xml' 'http://localhost:8070/api/v2/spdx/{applicationInternalId}/stages/build?format=xml'- u admin : admin123 - X GET - o 'spdx.xml' 'http://localhost:8070/api/v2/spdx/{applicationInternalId}/stages/build?format=xml'

扫描前生成 CycloneDX SBOM

CycloneDX可用于从源代码生成 SBOM。它们使用您的应用程序构建上下文来获取代码中引用的声明和传递依赖项的列表。您可以使用他们的工具作为构建过程的一部分，并将其纳入您的 Sonatype 评估中。我们的分析器会将这些结果与您代码中发现的任何内容相结合，以获得您的应用程序的完整物料清单。 

第三方 SBOM 的主要考虑因素

• 使用上面详述的命名要求，让 Sonatype 分析器拾取 SBOM。

• 第三方工具的结果可能与我们内置分析器的结果不同。

• 他们可能使用不同的方法来确定什么是组件、什么不是组件。

• 他们可能会误报或包含不完整的谱系数据，而这些数据在我们的分析中被拒绝。

• 它们可能只包含清单中报告的组件，而缺少源中重命名或嵌入的组件。

• 它们可能包括/排除开发范围中使用的组件，这些组件通常不包括在最终应用程序中。

作为最佳实践，您需要比较不同分析仪的结果，以确定哪种模型最符合您的要求和期望。一旦对结果感到满意，我们建议您在整个组织内标准化该方法，以在整个构建生命周期中保持一致性。

管理 SBOM

您需要决定如何管理和使用从您的投资组合中生成的 SBOM。到目前为止，整个行业还没有标准化执行此操作的最佳方法。以下是我们与合作伙伴取得成功的一些建议。

存储您的 SBOM

组织使用二进制存储库（例如 Nexus Repository）来存储和管理其在私有托管存储库中构建的工件。 

• 您可以将 SBOM 与 Java 应用程序一起存储在 Maven 存储库中以供快速参考。 

• 对于非 Java 应用程序，您可以选择将 SBOM 上传到原始存储库以便于访问。 

• 提前计划并为 SBOM 使用清晰的命名空间和发布详细信息，以使事情更易于管理。 

• 标记 API 可用于将您的发布元数据与存储库中的组件关联起来。

OWASP CycloneDX 推出了 BOM Exchange API，以便更好地管理跨组织的 SBOM。查看他们的BOM 存储库服务器了解详细信息。 

搜索依赖项

当尝试查找使用了哪个应用程序的特定依赖项时，请从 IQ Server 高级搜索开始，以避免必须导出并打开每个应用程序 SBOM。 从我们的0 天漏洞最佳实践
中了解更多信息。

分析组织的依赖性

IQ Data Insight - Stack Divergence 工具非常适合分析整个组织的组件趋势。