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

1. SBOM 基础概念：从一份清单说起

大家好，我是你们的讲师。今天咱们聊聊 SBOM——软件物料清单。这词儿这几年特别火，尤其是 SolarWinds 事件之后，几乎成了供应链安全的标配。

说白了，SBOM 就是一份「软件成分清单」。你想想看，你点一份外卖，包装上会印着配料表、生产日期、保质期。软件也一样，一个应用里用了哪些开源组件、什么版本、依赖关系如何、许可证是什么——这些信息，就是 SBOM 要记录的东西。

一句话定义：SBOM（Software Bill of Materials）是软件供应链的「成分表」，它列出了构建软件所涉及的所有组件、版本、依赖关系和许可证信息。

1.1 为什么我们需要 SBOM？

我在 2019 年接手过一个金融项目，客户要求我们提供所有第三方组件的清单。当时团队里没人当回事，觉得「不就是列个表嘛」。结果一查，项目里用了 200 多个 npm 包，其中 30 多个已经不再维护，还有 5 个存在已知漏洞。嗯，那场面，挺尴尬的。

从那以后，我养成了一个习惯：每个项目启动时，先把 SBOM 建起来。为什么？因为：

漏洞管理：Log4j 爆发时，有 SBOM 的企业 2 小时内就能定位受影响系统，没有的得花几周人工排查
许可证合规：GPL 传染性许可证可能让你的商业代码被迫开源，SBOM 能帮你提前发现
供应链透明度：你知道你的依赖的依赖是什么吗？SBOM 能递归展示整个依赖树
应急响应：当某个底层库被爆出后门，SBOM 能告诉你「哪些产品受影响、影响多深」

1.2 SBOM 的四大组成要素

一份完整的 SBOM，至少包含四个核心要素。我习惯把它们叫做「四件套」：

要素	说明	示例
组件	软件中包含的每一个独立单元，包括开源库、商业组件、内部模块	`log4j-core`、`express`、`my-company-utils`
版本	每个组件的精确版本号，不能是「latest」或「^1.0.0」这种范围	`2.17.1`、`4.18.2`、`1.3.0-beta`
依赖关系	组件之间的引用关系，包括直接依赖和传递依赖	`A → B → C`（A 依赖 B，B 依赖 C）
许可证	每个组件的开源许可证类型，用于合规审查	`Apache-2.0`、`MIT`、`GPL-3.0`

我的经验：版本号一定要精确到 patch 版本。我曾经见过一个项目，package.json 里写的是 "lodash": "^4.17.0"，结果 CI 构建时拉到了 4.17.21，而安全扫描报告里说 4.17.20 以下有漏洞。你猜怎么着？审计时根本说不清到底用的是哪个版本。所以，锁文件（lock file）必须提交到代码库。

1.3 依赖关系：不只是「父子关系」

依赖关系是 SBOM 里最容易出问题的部分。你以为你只用了 10 个包，但它们的依赖的依赖……加起来可能超过 500 个。这就是所谓的「传递依赖」。

举个例子：

你的应用
  └─ react@18.2.0
       └─ loose-envify@1.4.0
            └─ js-tokens@4.0.0
  └─ axios@1.6.0
       └─ follow-redirects@1.15.4
            └─ (无依赖)

你看，你只直接依赖了 react 和 axios，但实际引入了 4 个包。如果 loose-envify 被植入恶意代码，你的应用也会遭殃。这就是为什么 SBOM 必须递归展开所有依赖层级。

避坑指南：我曾经遇到过一个案例，某团队在 SBOM 里只列出了直接依赖，结果安全审计时漏掉了 3 个高危漏洞——它们都藏在传递依赖里。从那以后，我要求所有 SBOM 必须包含「完整依赖树」，不能只列第一层。

1.4 许可证：被忽视的合规风险

许可证这块，很多开发团队不太在意。但法务部门会在意，而且是在你准备上市或融资的时候。

常见的许可证类型：

MIT / Apache-2.0 / BSD：宽松许可证，商用友好，基本没有限制
GPL-2.0 / GPL-3.0：强传染性，如果你的软件使用了 GPL 组件，整个软件可能被迫开源
LGPL：弱传染性，动态链接可以规避，静态链接需要开源
AGPL：网络服务也算分发，云厂商特别要注意
Commons Clause / SSPL：附加限制条款，可能禁止商用

我建议你在 SBOM 里不仅要列出许可证类型，还要标注「合规状态」——是允许、需要审核、还是禁止使用。这样法务审查时能快速定位风险。

1.5 SBOM 在软件供应链中的角色

咱们用一张图来理解 SBOM 在整个供应链里的位置：

从这张图能看出来，SBOM 不是一份静态文档，而是贯穿整个供应链的「数据纽带」。上游组件供应商提供 SBOM，开发团队在构建时生成 SBOM，安全团队和法务部门消费 SBOM 做决策，客户和监管机构审计 SBOM。

我个人认为，SBOM 最大的价值在于「把不可见变成可见」。以前我们只知道「这个应用用了 Spring Boot」，但不知道 Spring Boot 里面引用了哪些库、这些库有没有漏洞。有了 SBOM，整个依赖树一目了然。

1.6 小结：SBOM 不是什么？

最后，我想澄清几个常见的误解：

SBOM 不是漏洞报告：它只列出组件信息，不包含漏洞详情。但你可以把 SBOM 喂给漏洞数据库，自动匹配出风险
SBOM 不是一次性的：每次构建、每次依赖更新，都应该重新生成 SBOM。我见过有些团队一年才更新一次，那基本等于没有
SBOM 不是只有大厂才需要：哪怕你只写了一个内部工具，只要它引用了第三方代码，就应该有 SBOM。小项目更容易被忽视，但风险一样存在

一句话总结：SBOM 是软件供应链的「成分表」，它告诉你「你吃进去的是什么」。没有它，你就是在闭着眼睛吃饭——可能很香，也可能吃进去一颗钉子。