📚 课程目录第1章 SBOM基础概念

1. SBOM 基础概念：什么是 SBOM、为什么需要 SBOM、行业标准

各位同学好，我是老赵。今天咱们开始《SBOM 清单生成实战》的第一章。

说实话，我接触 SBOM 这个概念，最早是在 2019 年。当时帮一家金融客户做容器化改造，结果安全审计那边卡住了——人家问：你这一堆镜像里到底用了哪些开源组件？版本号多少？有没有已知漏洞？

我当时就懵了。几十个镜像，几百个依赖，靠人工翻？不现实。后来才接触到 SBOM 这个概念。嗯，今天咱们就把这个基础打牢。

1.1 什么是 SBOM？

SBOM，全称 Software Bill of Materials，软件物料清单。

说白了，就是一份清单。跟你去超市买东西的小票一样，上面列着你这个软件里用了哪些组件、什么版本、从哪里来的、许可证是什么。

我习惯把它理解成「软件的成分表」。你买一包薯片，包装袋后面会写：土豆、植物油、食用盐、食品添加剂……SBOM 就是软件世界的成分表。

核心定义：SBOM 是软件供应链中所有组件的结构化清单，包含组件名称、版本号、供应商、依赖关系、许可证等信息。

一个标准的 SBOM 条目，通常包含这些字段：

字段	说明	示例
组件名称	软件包的名称	log4j-core
版本号	精确版本或版本范围	2.14.1
供应商	组件作者或组织	Apache Software Foundation
许可证	开源许可证类型	Apache-2.0
依赖关系	该组件依赖的其他组件	log4j-api:2.14.1
校验和	用于验证组件完整性	SHA256:abc123...

你想想看，如果没有这份清单，你根本不知道你的软件里塞了什么东西。尤其是现在，一个 Java 项目随便拉一下依赖，几十上百个包太正常了。

1.2 为什么需要 SBOM？

这个问题我经常被问到。很多开发者的第一反应是：我代码能跑就行，搞什么清单？

好，我讲个真实案例。

2021 年底，Log4Shell 漏洞爆发。当时我正好在帮一家电商平台做安全加固。他们生产环境里跑着 200 多个微服务，每个服务都依赖 Log4j。但问题是——没人知道具体哪些服务用了 Log4j，更不知道用的是哪个版本。

结果呢？全团队花了整整两周，一个一个服务排查。那两周，我每天只睡四个小时。如果有 SBOM，一个 grep 命令就能搞定。

所以，为什么需要 SBOM？我总结了四个核心原因：

漏洞应急响应——漏洞出来，三分钟就能定位受影响的服务，而不是两周。
许可证合规——你的项目用了 GPL 协议的库？那你的代码可能也得开源。SBOM 能帮你提前发现。
供应链风险管理——你知道你的依赖的依赖是什么吗？SBOM 能展示完整的依赖树。
客户与合规要求——现在很多大客户、政府项目，采购时就要求你提供 SBOM。没有？抱歉，不合作。

注意：我曾经见过一个团队，因为不知道项目里用了某个 GPL 协议的库，结果被法务部门找上门。最后不得不重写那一块功能，损失了三个月的人力。SBOM 不是可有可无，是合规的底线。

1.3 SBOM 的行业标准

说到标准，目前业界主流有两个：SPDX 和 CycloneDX。我两个都用过，各有千秋。

1.3.1 SPDX

SPDX（Software Package Data Exchange）是最早的标准，由 Linux 基金会维护。它诞生于 2011 年，资历最老。

我个人习惯用 SPDX 的场景是：许可证合规审计。因为 SPDX 对许可证的描述非常详细，支持 600+ 种许可证的标识。

SPDX 的格式长这样：

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: my-app-sbom
PackageName: log4j-core
PackageVersion: 2.17.1
PackageLicenseDeclared: Apache-2.0
PackageSupplier: Organization: Apache Software Foundation
PackageChecksum: SHA256: a1b2c3d4...

嗯，这里要注意：SPDX 的格式偏「文档化」，可读性不错，但机器解析起来稍微有点啰嗦。

1.3.2 CycloneDX

CycloneDX 由 OWASP 社区推动，2017 年才出来。它更轻量，更面向现代应用。

我建议在 容器镜像、云原生场景 下优先用 CycloneDX。它的 JSON 格式非常干净，跟 CI/CD 流水线集成起来很顺手。

CycloneDX 的 JSON 示例：

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "version": "2.17.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    }
  ]
}

看到那个 purl 字段了吗？这是 Package URL，能精确定位到具体的包管理器、包名和版本。这个设计很聪明，我特别喜欢。

1.3.3 两个标准的对比

维度	SPDX	CycloneDX
维护组织	Linux 基金会	OWASP
首次发布	2011 年	2017 年
核心优势	许可证描述详尽	轻量、JSON 友好
适用场景	法律合规、审计	CI/CD、容器、云原生
格式支持	Tag/Value、RDF、JSON	JSON、XML
包标识	SPDXID	Package URL (purl)

我的建议：如果你刚开始做 SBOM，从 CycloneDX 入手会更轻松。等团队成熟了，再考虑同时输出两种格式。我现在的项目就是两个都生成，SPDX 给法务看，CycloneDX 给 DevOps 用。

1.4 SBOM 知识体系总览

为了让你对本章内容有个整体印象，我画了一张图。它展示了 SBOM 的核心概念、价值驱动因素以及两大标准之间的关系。

这张图把本章的核心内容串起来了。中心是 SBOM，左边是它的定义，右边是它的价值，底部是两大标准。你把这个框架记住，后面学起来会轻松很多。

1.5 小结

好，第一章就到这里。咱们回顾一下：

SBOM 就是软件的成分表，记录了你项目里所有组件的详细信息。
它不是为了找麻烦，而是为了在出问题时能快速响应。
SPDX 和 CycloneDX 是两大主流标准，选哪个取决于你的场景。