4. 软件物料清单（SBOM）：从“黑盒”到“透明”的关键一步

说实话，我做了这么多年供应链安全，最头疼的问题就是——你根本不知道你的软件里到底有什么。

你买了一个开源组件，它依赖了另一个组件，那个组件又依赖了三个库。最后你的产品里可能藏着一个十几年前的老漏洞，而你毫不知情。这就是典型的“依赖地狱”。

怎么解决？答案就是 SBOM（Software Bill of Materials，软件物料清单）。说白了，它就像你买电器时附带的零件清单。有了它，你才能知道每个螺丝钉是哪来的、有没有问题。

4.1 SBOM 的定义与标准

SBOM 的核心思想很简单：把你的软件拆开，列出所有组件、版本、依赖关系、许可证信息。这样无论是做漏洞扫描、许可证合规，还是做国产化替代评估，你都有据可查。

但问题来了——大家格式不统一，怎么交换数据？所以有了两个主流标准：

标准	维护组织	特点	我的使用感受
SPDX	Linux 基金会	最早的标准，侧重许可证合规和文档化	适合做法律合规审查，文档很全，但有点重
CycloneDX	OWASP	轻量级，侧重安全漏洞和依赖关系	我个人更常用这个，生成快、解析也快

4.2 SBOM 的生成工具

标准定好了，接下来就是怎么生成。我推荐两个工具，都是我在项目中反复验证过的。

4.2.1 Syft：容器镜像和文件系统的“扫描仪”

Syft 是 Anchore 公司开源的，专门用来从容器镜像、文件系统里生成 SBOM。它支持 SPDX 和 CycloneDX 两种格式。

我记得有一次，客户拿了一个第三方提供的 Docker 镜像，里面到底装了啥谁都不知道。我用 Syft 一扫，好家伙，里面有个 Log4j 的旧版本，漏洞编号 CVE-2021-44228 赫然在列。客户当场就懵了。

用法很简单：

# 从 Docker 镜像生成 CycloneDX 格式的 SBOM
syft packages docker:myimage:latest -o cyclonedx-json > sbom.json

# 从文件系统生成 SPDX 格式
syft packages /path/to/project -o spdx-json > sbom.spdx.json

4.2.2 CycloneDX Maven Plugin：Java 项目的“亲儿子”

如果你做 Java 开发，尤其是 Maven 项目，这个插件简直是神器。它直接集成到 Maven 构建生命周期里，每次构建自动生成 SBOM。

我曾经帮一个金融客户做供应链安全评估，他们的项目有上百个依赖。手动整理？不可能。我直接在 pom.xml 里加了这个插件，一行命令搞定所有依赖的 SBOM。

配置示例：

<plugin>
    <groupId>org.cyclonedx</groupId>
    <artifactId>cyclonedx-maven-plugin</artifactId>
    <version>2.7.9</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>makeAggregateBom</goal>
            </goals>
        </execution>
    </executions>
</plugin>

运行 mvn package 后，会在 target/ 目录下生成 bom.json 或 bom.xml。

4.3 SBOM 在漏洞管理中的应用

生成 SBOM 只是第一步，怎么用才是关键。我总结了三层应用：

1. 漏洞匹配：把 SBOM 里的组件和 CVE 数据库做比对。比如你用 Syft 生成了 SBOM，然后导入到 Dependency-Track 或 OWASP Dependency-Check 里，自动告诉你哪些组件有已知漏洞。
2. 影响分析：当一个新的漏洞（比如 Log4Shell）爆出来时，你不需要翻遍所有项目。只需要拿着 SBOM 数据库一查，哪些项目用了受影响版本，一目了然。
3. 修复验证：升级组件后，重新生成 SBOM，对比前后差异，确保漏洞确实被修复了。

我举个例子。有一次某开源库爆出严重漏洞，我们团队有 50 多个微服务。要是挨个查，三天都搞不完。但因为我们之前强制要求每个服务都生成 SBOM 并上传到中央仓库，我写了个脚本，半小时就定位了所有受影响的服务。这就是 SBOM 的价值。

4.4 SBOM 的签名与验证

嗯，这里要特别强调一下。SBOM 本身也是数据，如果被篡改了怎么办？你拿着一个假的 SBOM 去做漏洞分析，结果全是错的。

所以，签名和验证是必须的。我推荐用 Sigstore 或者简单的 GPG 签名。

我曾经遇到过一个案例：某供应商提供了 SBOM，但我们扫描后发现组件列表和实际运行的不一致。后来一查，是有人在传输过程中篡改了 SBOM 文件。从那以后，我要求所有 SBOM 必须签名。

用 GPG 签名的示例：

# 签名
gpg --detach-sign --armor sbom.json

# 验证
gpg --verify sbom.json.asc sbom.json

用 Sigstore（更现代的方式）：

# 安装 cosign
cosign sign-blob --key cosign.key sbom.json

# 验证
cosign verify-blob --key cosign.pub --signature sbom.json.sig sbom.json

知识体系图

下面这张图是我自己画的，帮你理清 SBOM 的核心逻辑：

你看，整个体系其实就四个环节：标准 → 工具 → 应用 → 安全。环环相扣，少一个都不行。

最后说一句，SBOM 不是银弹。它只是一个工具，关键还是看你怎么用。但如果你连 SBOM 都没有，那供应链安全就是一句空话。

---

公众号:蓝海资料掘金营，微信deep3321