通过 SBOM 确保 Java 应用的供应链安全

本文最初发表于作者的个人站点，经作者Thomas Vitale授权，由 InfoQ 中文站翻译分享。

软件供应链的安全性从未像现在这么重要，保护我们的系统免受不良行为者和漏洞的侵害是一项持续的挑战。对于 Java 应用程序中的所有库和依赖关系，你是否具备完全的可见性和透明度呢？

准确了解应用程序中包含的每个组件对于执行漏洞扫描和许可证合规性检查等操作都至关重要。如果不知道软件系统的内部结构，又如何确保其安全性呢？

软件物料清单（Software Bill of Materials，SBOM）是“软件的嵌套清单，是构成软件组件的配料列表”（NTIA）。在本文中，我将解释为何我们要使用 SBOM 作为供应链安全策略的一部分，以及业界都有哪些可用的标准。

然后，我将向你展示如何在软件生命周期的不同阶段为 Java 应用程序生成 SBOM，并解释每项技术的优缺点。你将会看到如何为 Java 源码、JAR 制品（artifact）、GraalVM 原生可执行文件和容器镜像创建 SBOM。我还将介绍如何使用 Gradle 或 Maven 将生成 SBOM 作为构建的一部分。让我们开始吧！

本文实例的源码可以在GitHub上获取。

为何要使用 SBOM？

在设计供应链安全策略时，SBOM 是关键的一环。SBOM 能够“识别并列出软件组件、组件的相关信息以及它们之间的供应链关系”（NTIA）。例如，对于每个软件组件，SBOM 可以包含版本号、许可证描述符、供应商的详细信息、哈希摘要值、是否为传递依赖等。

通过这份清单文件，扫描器可以检查每个组件的完整性、已知的安全漏洞、是否符合许可策略以及是否有更新的版本。来自 SBOM 的数据还可以输入资产管理和采购的企业流程。这些用例是我们需要 SBOM 的部分原因。

此外，我们行业的主要安全框架和流程都推荐使用 SBOM。根据美国总统第14028号行政命令（Executive Order，EO）：“提高国家的网络安全”，向美国联邦机构提供的软件必须使用 SBOM。不久之后，软件供应商也必须遵守欧盟的“网络弹性法案”。

在本文中，我将重点介绍如何为 Java 应用程序生成高质量的 SBOM。后续的文章将会深入介绍如何使用它们来解决供应链安全策略中的多个使用场景。例如，我将会讨论使用Trivy进行漏洞扫描以及使用Dependency Track进行持续供应链风险管理。

SBOM 的数据格式

我们希望得到结构化的 SBOM 文档，以便于自动化系统能够处理它的数据。CycloneDX 和 SPDX 是两种最广泛使用的且机器可读的 SBOM 格式。

CycloneDX是“一种全栈物料清单（BOM）标准，能够为降低网络风险提供先进的供应链功能”。该规范支持 SBOM 和其他使用场景，比如 VEX（漏洞可利用性交换，Vulnerability Exploitability eXchange）和 VDR（漏洞披露报告，Vulnerability Disclosure Reports），我将会在以后关于漏洞管理的文章中介绍这些使用场景。它还支持各种类型的物料清单，比如 SaaSBOM（软件即服务物料清单，Software-as-a-Service Bill of Materials）、KBOM（Kubernetes 物料清单，Kubernetes Bill of Materials）和 ML-BOM（机器学习物料清单，Machine Learning Bill of Materials）。CycloneDX 是OWASP的旗舰项目，目前正在寻求国际 Ecma 的标准化。

SPDX（软件包数据交换，Software Package Data Exchange）是“交流软件物料清单信息的开放标准，包括出处、许可证、安全性和其他相关的信息”。目前正在开发的 SPDX 3.0 将支持 SBOM 之外的更多使用场景，比如 VEX 和其他类型的 BOM。该规范得到了Linux基金会的支持，并被认定为国际标准 ISO/IEC 5962:2021。

这两种格式都在业界得到了应用，并在供应链安全生态系统中获得了广泛支持。我不打算讨论该采用哪种格式，因为这取决于预期的使用场景、企业的具体需求以及与当前系统集成的可能性。目前，有一些工具能够将其中的某种格式转换成另一种格式。

在本文中，我将使用 CycloneDX，因为现在它在 Java 生态系统中得到了更好地支持。在可能实现的地方，我都会给出如何将示例转换为使用 SPDX 的提示。

什么是好的 SBOM？

在选择了定义 SBOM 的标准格式后，那么我们该讨论一下什么才算好的 SBOM 了。影响 SBOM 质量的因素有很多。

清单中每个组件包含的信息决定了 SBOM 可用于哪些使用场景。如果你想将 SBOM 用于许可证合规性检查，那么每个组件都必须包含许可证的详细信息。如果你想要遵循美国总统第14028号行政命令（Executive Order，EO）：“提高国家的网络安全”，那么每个 SBOM 中都必须包含一组最基本的元素。

应用程序最终 SBOM 中所包含的详细信息的深度会受到软件生命周期中 SBOM 生成时机的影响。创建 SBOM 的工具也会影响最终结果的质量。在下面的章节中，我将带领你使用一些不同的工具，在不同阶段（源代码、构建、可执行文件）生成 SBOM。

由于生成和使用 SBOM 的方式多种多样，因此评估 SBOM 的质量可能是一项很具挑战性的事情。OWASP软件组件验证标准项目背后的社区发布了一个BOM成熟度模型，该模型提供了“一个正式的结构，在此结构中可以对物料清单的各种能力进行评估”。该模型还支持将 BOM 信息组织成与使用场景相关的类别（如应用程序的安全性、许可证和采购信息）以及验证其合规性的配置文件。

此外，还出现了可以扫描 SBOM 并根据特定标准进行评分的工具。例如，你可以使用sbomqs（SBOM 质量评分，SBOM Quality Score），这是SBOM Benchmark项目的一个实验性工具。

为 Java 制品生成 SBOM

假设你已经组装了 Java 制品（JAR 或容器镜像）。在这种情况下，我们可以使用扫描制品的工具生成 SBOM，并搜索其中包含的软件包。

在软件生命周期的这一阶段创建的 SBOM 应该能够保证最终应用制品的所有组件的可见性，包含运行时所需的依赖项，如操作系统库和 Java 运行时（适用于容器镜像）。最终结果在很大程度上依赖于生成 SBOM 的工具，也就是它能找到多少个组件？

即便好的工具可以识别应用程序制品中包含的（几乎）所有软件组件，但是每个组件的信息深度可能会有所不足。但这是一件坏事儿吗？这要看具体情况。例如，在本阶段生成的 SBOM 可能非常适合进行漏洞扫描。相比之下，它们可能缺少验证许可证合规性或跟踪依赖关系所需的必要信息。根据你的需求，可以考虑是否有必要将 SBOM 生成转移到软件生命周期的更早阶段（稍后将会进行讲解），以解决现阶段无法实现的使用场景。

对于第三方应用程序，我建议要求供应商在交付时就提供 SBOM，而不是自己通过他们的制品生成 SBOM。根据你所在的国家和行业，这甚至可能是（或很快成为）法律要求。如果是开源项目，可以考虑使用本文中学到的技术，提交 pull request 以添加 SBOM 的生成。

为 JAR 文件生成 SBOM

为打包成 JAR 制品的 Java 应用生成 SBOM 需要一个支持从 JAR 中查找和提取信息的工具。Syft是一款用于生成 SBOM 的流行开源工具，可用于 JAR 制品。

你可以查阅它的文档，了解如何在你的机器上安装该工具。在 macOS 和 Linux 上，可以使用 Homebrew 软件包管理器。

brew install syft

接下来，下载包含本文所有样例的Git仓库，并导航至本节将使用的应用程序。该样例是基于 Spring Boot 的，但是本文所涉及的内容同样适用于所有 Java 应用，与框架无关。

git clone https://github.com/ThomasVitale/supply-chain-security-javacd sbom/cyclonedx/gradle

然后，将样例应用程序打包成 JAR 制品。该项目配置了 Java 21，如果你还有安装它的话，请参考SDKMAN进行安装。

./gradlew bootJar

借助SDKMAN，安装 Java 21 只需一条sdk install java 21-tem命令即可。

最后，你可以使用 Syft 从 Java 制品开始为应用程序生成 SBOM。

syft build/libs/demo-sbom-cdx-gradle-1.0.jar -o cyclonedx-json --file bom-syft.cdx.json

请参阅生成的 SBOM（bom-syft.cdx.json）以熟悉 CycloneDX 格式的结构。

要生成基于 SPDX 格式的 SBOM，请将-o cyclonedx-json替换为-o spdx-json。

为容器镜像生成 SBOM

要为打包成容器镜像的 Java 应用程序生成 SBOM，需要一种支持从 JAR 中查找和提取信息、识别操作系统包和 Java 运行时。Syft 也支持这种使用场景。

我们使用与上一个样例相同的应用程序，将其打包为容器镜像。在继续之前，请确保已经运行 Podman 或 Docker。Spring Boot 依赖 Cloud Native Buildpacks 构建生产级别的容器映像，无需任何 Dockerfile。

./gradlew bootBuildImage

如果你使用 Quarkus 的话，你可以选择使用 Cloud Native Buildpacks 集成。首先，在属性文件中配置构建器镜像：quarkus.buildpack.jvm-builder-image=paketobuildpacks/builder-jammy-tiny。然后，运行./gradlew build -Dquarkus.container-image.build=true命令来构建镜像。

然后，就可以使用 Syft 从容器镜像开始为应用程序生成 SBOM。

syft demo-sbom-cdx-gradle:1.0 -o cyclonedx-json --file bom-oci-syft.cdx.json

要生成基于 SPDX 格式的 SBOM，请将-o cyclonedx-json替换为-o spdx-json。

如果你查看生成的 SBOM(bom-oci-syft.cdx.json)，就会发现与之前相同的 Java 依赖关系，但是还包含了 Syft 可以在镜像内的 Ubuntu 文件系统中找到的所有软件包的列表。

使用 Cloud Native Buildpacks 的 SBOM

在上一节中，我们使用了 Spring Boot 的bootBuildImage Gradle task 来容器化 Java 应用程序。在幕后，Spring Boot 使用了 Cloud Native Buildpacks，这是一种无需 Dockerfile 就能将应用程序源代码转换为容器镜像的规范。

更具体地说，Spring Boot 使用了Paketo Buildpacks实现，该实现使用 Syft 为构建的镜像的每一层均生成一个 SBOM。当需要为使用 Buildpacks 构建的容器镜像创建 SBOM 时，你可以从镜像中提取自动生成的 SBOM，而不用像之前那样显式创建。

如果你想要提取由 Buildpacks 生成的 SBOM，请安装pack CLI。你可以查阅其文档了解如何在你的机器上安装该工具。在 macOS 和 Linux 上，可以使用 Homebrew 软件包管理器。

brew install buildpacks/tap/pack

然后，使用 pack 从镜像的每一层抽取 SBOM。

pack sbom download demo-sbom-cdx-gradle:1.0 -o sbom-layers

你可以在sbom-layers目录中找到 SBOM。在下面的示例中，你可以看到每一层都有一个或多个不同格式的 SBOM。

$ tree sbom-layers

sbom-layers└── layers    └── sbom        └── launch            ├── buildpacksio_lifecycle            │   └── launcher            │       ├── sbom.cdx.json            │       ├── sbom.spdx.json            │       └── sbom.syft.json            ├── paketo-buildpacks_ca-certificates            │   └── helper            │       └── sbom.syft.json            ├── paketo-buildpacks_executable-jar            │   ├── sbom.cdx.json            │   └── sbom.syft.json            ├── paketo-buildpacks_native-image            │   ├── sbom.cdx.json            │   └── sbom.syft.json            └── sbom.legacy.json

这是 Buildpacks 一个便利的特性，它可以生成比镜像构建后更高质量的 SBOM。不过，从镜像中提取 SBOM，而且与供应链生态系统中的其他工具集成也有些难度。此外，它的行为可以更加具有一致性。不同的 buildpacks 会生成不同格式的 SBOM。上述样例中唯一不变的是 Syft 格式，这需要在集成场景中明确转换为 CycloneDX 或 SPDX 格式。

有关 Cloud Native Buildpacks 中 SBOM 支持的更多信息，请查看 Buildpacks和Paketo的文档。

使用 JReleaser 生成 SBOM

JReleaser是编排软件发布的强大工具，为 Java 项目提供了许多有用的特性。其中，JReleaser 可以为我们编排 SBOM 的生成。它基于最终的应用程序制品（JAR 或容器镜像），并使用 Syft 或 CycloneDX CLI 来生成 SBOM。

你可以查阅项目的文档，了解如何配置该特性。关于 JReleaser 的阐述值得单独写一篇文章，在此我就不再展开叙述了，但是我依然建议你了解一下这个工具。

为 Java 源码生成 SBOM

如果你可以访问 Java 应用程序的源码，那么就可以采用某种工具来生成 SBOM，该工具会扫描项目并搜索其中引用的软件包。

在软件开发生命周期的这个阶段创建 SBOM 能够确保应用程序项目的所有组件的可见性，包括构建和测试所需的依赖项，比如注解处理器和测试库。它的结果在很大程度上取决于生成 SBOM 所使用的工具，但是我们希望它能够比前一种策略更加详细，因为工具可以完全访问源代码。

在本阶段生成的 SBOM 非常适合进行许可证合规性检查，以及查找影响软件项目中所使用组件的已知漏洞。相比之下，它们可能会遗漏运行时所需的依赖关系，这通常对应以容器镜像分发应用程序的情况。此外，这些 SBOM 通常会包含比最终制品更多的内容（比如测试依赖项），因此不太适合用在采购这样的场景中。

正如前文所述，SBOM 可以根据特定的使用场景进行定制。根据你所需要的能力，可以考虑在软件生命周期的不同阶段创建 SBOM，并使用它们来满足特定的需求。

CycloneDX 项目提供了一个名为cdxgen的工具，它可以全面了解 Java 项目中使用的所有依赖，同时支持 Gradle 和 Maven。这就是我们接下来要使用的工具。

请查阅文档了解如何在你的机器上安装 cdxgen。在 macOS 和 Linux 上，可以使用 Homebrew 软件包管理器。

brew install cdxgen

你可以在本文Git仓库所包含的应用程序（sbom/cyclonedx/gradle）中尝试这一策略。我们可以使用 cdxgen 从项目源代码开始为应用程序生成 SBOM。

FETCH_LICENSE=true cdxgen -o bom-cdxgen.cdx.json --spec-version 1.5

请查看生成的 SBOM（bom-cdxgen.cdx.json），并将其与之前用 Syft 创建的 SBOM 进行对比，你注意到有什么差异吗？

要生成 SPDX 格式的 SBOM，可以使用Trivy并执行命令trivy fs --format spdx-json --output bom-trivy.spdx.json .。对于 Maven 项目，该命令开箱即用。对于 Gradle 项目，则需要启用依赖版本锁定特性，否则 Trivy 将不知道如何找到 Java 依赖关系。

在本文的Git仓库中，还有一个使用 Maven 的 Java 应用样例（sbom/cyclonedx/maven），你可以使用它来测试基于 cdxgen 来生成 SBOM。结果与 Gradle 样例非常类似。

cdxgen 工具非常强大，它支持多种语言和生态系统，甚至还能通过 profile 提供专用的选项，从而根据使用场景（应用安全性、研究、运维、安全危险建模和许可证合规性）来生成 SBOM。你可以在该项目的网站上找到更多信息。

通过 profile，cdxgen 可以生成针对特定使用场景定制和优化的 SBOM。例如，如果你需要用于研究目的的 SBOM，可以运行以下命令： cdxgen -o bob-research.cdx.json --spec-version 1.5 --profile research，这将启用深度和证据模式。你可以尝试将结果与迄今为止生成的 SBOM 进行比较，发现它们之间的差异了吗？

为 Java 构建生成 SBOM

在讨论了从应用程序制品（JAR、容器镜像）和源码生成 SBOM 的方案之后，现在我们研究一下如何将生成过程作为构建生命周期的一部分。对于 Java 应用，我们需要有一个工具挂接到构建过程中，并提取用来组装软件的每个组件的信息。

在软件开发生命周期这一阶段创建 SBOM 应该能够保证用于构建应用程序的所有组件的可见性。由于生成过程与构建生命周期挂钩，所以我们可以完全控制包含哪些组件，并获得比其他策略更深入的结果。

在这一阶段生成的 SBOM 非常适合大多数使用场景，比如漏洞扫描、许可证合规性和采购。通常来讲，我们可以对操作进行定制，以便于在最终的 SBOM 中只包含某些特定类型的依赖（比如，如果你想排除掉测试依赖，这就非常有用）。但是，这些 SBOM 可能会遗漏运行时所需的依赖，在使用容器镜像分发的应用程序中通常会遇到这种情况。

我建议将 SBOM 生成作为 Java 构建生命周期的一部分，因为这样可以生成质量更高、更详细的文档，实现供应链风险管理所需的众多功能。然后，基于具体情况和需求，你可能希望用其他阶段生成的 SBOM 来完善生成的文档，并对构建生命周期中无法实现的使用场景进行定制。

CycloneDX项目为 Gradle 和 Maven 提供了两个方便的插件，能够使 SBOM 生成过程成为构建生命周期的一部分。我们接下来就将使用这两个插件。

使用 Gradle 为 Java 应用生成 SBOM

我们首先探讨一下如何使用CycloneDX Gradle插件为 Java 应用程序生成 SBOM。你可以在本文Git仓库（sbom/cyclonedx/gradle）包含的应用程序中尝试这一策略。

首先，将插件添加到 build.gradle 文件中。

plugins {    id 'org.cyclonedx.bom' version '1.8.1'}

该插件添加了一个cyclonedxBom task，用来为应用程序生成 SBOM。我们尝试一下。

./gradlew cyclonedxBom

默认情况下，SBOM 会生成在build/reports/bom.json文件中。你可以将结果与其他阶段创建的 SBOM 进行比较，是否能够发现有什么差异？

我们可以根据需要自定义插件。例如，我们将其配置为使用 JSON 的 CycloneDX 模式 1.5 版。你还可以将其作为构建步骤的一部分，这样每次构建应用程序的时候都会自动生成 SBOM。

cyclonedxBom {    projectType = "application"    outputFormat = "json"    schemaVersion = "1.5"}tasks.build.finalizedBy 'cyclonedxBom'

该插件提供了多种定制化，包括希望在最终的 SBOM 中都包含哪些依赖项（运行时、编译和测试）。你还可以传递有关应用程序的其他元数据，比如组织的联系方式以及项目使用的许可证。请参阅插件文档，以了解所有可用的配置。

如果要生成基于 SPDX 格式的 SBOM，可以使用SPDX Gradle插件。

使用 Maven 生成 Java 应用的 SBOM

我们探讨一下如何使用CycloneDX Maven插件为 Java 应用程序生成 SBOM。你可以在本文 Git 仓库（sbom/cyclonedx/maven）包含的应用程序中尝试这一策略。

首先，将插件添加到pom.xml文件中。

<build>    <plugins>        <plugin>            <groupId>org.cyclonedx</groupId>            <artifactId>cyclonedx-maven-plugin</artifactId>            <version>2.7.10</version>        </plugin>    </plugins></build>

该插件添加了一个makeAggregateBom goal 来为应用程序生成 SBOM。我们尝试一下。

./mvnw cyclonedx:makeAggregateBom

默认情况下，SBOM 会生成在target/bom.json文件中。你可以将结果与其他阶段创建的 SBOM 进行比较，是否能够发现有什么差异？

我们可以根据需要自定义插件。例如，我们将其配置为使用 JSON 的 CycloneDX 模式 1.5 版。你还可以将其作为构建步骤的一部分，这样每次构建应用程序的时候都会自动生成 SBOM。

<build>    <plugins>        <plugin>            <groupId>org.cyclonedx</groupId>            <artifactId>cyclonedx-maven-plugin</artifactId>            <version>2.7.10</version>            <executions>                <execution>                    <phase>package</phase>                    <goals>                        <goal>makeAggregateBom</goal>                    </goals>                </execution>            </executions>            <configuration>                <projectType>application</projectType>                <outputFormat>json</outputFormat>                <schemaVersion>1.5</schemaVersion>            </configuration>        </plugin>    </plugins></build>

该插件提供了多种定制化，包括希望在最终的 SBOM 中都包含哪些依赖项（运行时、编译和测试）。你还可以传递有关应用程序的其他元数据，比如组织的联系方式以及项目使用的许可证。请参阅插件文档，以了解所有可用的配置。

如果要生成基于 SPDX 格式的 SBOM，可以使用SPDX Maven插件。

为 GraalVM 原生可执行文件生成 SBOM

在最后一节中，我将介绍在使用 GraalVM 将 Java 应用程序编译为原生可执行文件时，生成 SBOM 的方案。

GraalVM的原生镜像模式具有很多优势，比如即时启动时间、即时峰值性能和更低的内存消耗。从安全的角度来看，与标准的 JVM 应用程序相比，使用 GraalVM 编译的原生可执行文件的攻击面也更小。原因在于，GraalVM 只编译从main()方法开始的代码中可达的路径。其他任何内容均不会包含在最终结果中。

关于 GraalVM 提供的额外安全功能，我将在今后有关漏洞管理的文章中详细阐述。现在，我想指出的是，最终制品将不包含任何 JAR 文件，这意味着扫描器在使用常规技术分析原生可执行文件时无法找到任何组件。

在处理原生可执行文件时，我们无法直接扫描最终制品以生成 SBOM。相反，我们需要将 SBOM 的生成步骤转移到软件开发生命周期的早期阶段。我之前介绍过的源代码和构建生命周期策略都是可行的，但它们包含的可能是编译到最终可执行文件中的实际依赖项的超集。

为了获得更准确的结果，Oracle GraalVM 发行版在编译应用程序时提供了一个试验性的SBOM生成特性。该功能在底层使用了 Syft，目前仅支持 CycloneDX 格式。

作为 GraalVM 编译过程的一部分而生成的 SBOM 的质量与我在本文中提到的第一种策略大致相同。例如，它适用于漏洞管理场景，但不适用于许可证合规性检查的场景，因为最终结果中可能缺少必要的信息。

在继续示例之前，请确保已安装 Oracle GraalVM 并将其设置为项目中的默认 Java 版本和发行版。您可以使用SDKMAN执行此操作。

sdk install java 21-graalsdk use java 21-graal

使用 Gradle 为 GraalVM 生成 SBOM

我们看一下如何使用 Gradle 为 GraalVM 的原生应用程序生成 SBOM。你可以在本文Git仓库（sbom/cyclonedx/gradle-native）所包含的应用程序中尝试这一策略。

首先，在build.gradle文件中配置 GraalVM Gradle 插件，启用 SBOM 生成功能。

graalvmNative {    binaries {        configureEach {            buildArgs.add("--enable-sbom=cyclonedx,export")        }    }}

然后，将应用编译为原生可执行文件。

./gradlew nativeCompile

作为原生编译过程的一部分，这里会使用 Syft 并按照 CycloneDX 格式生成 SBOM。SBOM 的一个副本会包含在制品本身中，因为我们在配置中添加了export标记，所以它也会导出到build/native/nativeCompile/demo-sbom-cdx-gradle-native.sbom.json中。你可以使用原生镜像探查工具（Native Image Inspection Tool）检查导出的 SBOM，甚至提取嵌入到原生可执行文件中的 SBOM。

目前，我们不能使用 SPDX 格式生成 SBOM。Oracle GraalVM 仅支持 CycloneDX。

使用 Maven 为 GraalVM 生成 SBOM

我们看一下如何使用 Maven 为 GraalVM 的原生应用程序生成 SBOM。你可以在本文Git仓库（sbom/cyclonedx/maven-native）所包含的应用程序中尝试这一策略。

首先，在pom.xml文件中配置 GraalVM Maven 插件以启用 SBOM 生成功能。

<build>    <plugins>        <plugin>            <groupId>org.graalvm.buildtools</groupId>            <artifactId>native-maven-plugin</artifactId>            <configuration>                <buildArgs combine.children="append">                    <buildArg>--enable-sbom=cyclonedx,export</buildArg>                </buildArgs>            </configuration>        </plugin>    </plugins></build>

然后，将应用编译为原生可执行文件。

./mvnw -Pnative native:compile

作为原生编译过程的一部分，这里会使用 Syft 并按照 CycloneDX 格式生成 SBOM。SBOM 的一个副本会包含在制品本身中，因为我们在配置中添加了export标记，所以它也会导出到target/demo-sbom-cdx-maven.sbom.json中。你可以使用原生镜像探查工具（Native Image Inspection Tool）检查导出的 SBOM，甚至提取嵌入到原生可执行文件中的 SBOM。

目前，我们不能使用 SPDX 格式生成 SBOM。Oracle GraalVM 仅支持 CycloneDX。

结论

本文介绍了软件物料清单(SBOM)的概念及其对软件供应链安全至关重要的原因。文章介绍了在软件开发生命周期的三个不同阶段为 Java 应用程序生成 SBOM 的主要策略，即源代码、构建和制品阶段。除此之外，我还讨论了 Gradle、Maven 和 GraalVM 中专门的集成方案。

创建 SBOM 只是开始。它真正的价值在于积极使用 SBOM 来管理软件的供应链安全风险。在今后的文章中，我将讨论如何将 SBOM 作为构建流水线的一部分进行分发，以及如何将它们用于漏洞扫描、许可证合规性、依赖关系管理和其他使用场景。敬请期待！