先不讲概念，先聊个真事。
Log4j 那天晚上，我在客户现场
2021 年 12 月，我记得很清楚，那天我正在银行客户现场做交付。
下午四五点的时候，客户的安全团队突然在群里炸了：Log4j 出了一个远程代码执行漏洞，CVSS 满分 10 分，影响范围极广。
攻击方式简单到离谱——用户在输入框里敲一行 ${jndi:ldap://xxx}，你的服务器就能被别人接管。不用登录，不用提权，直接 RCE。
然后接下来的事情，我估计很多人都经历过：
安全团队问开发："我们系统里有没有用 Log4j？"
开发说："应该有吧，我查查。"
这一查，就是好几天。
客户的核心交易系统大概有 200 多个微服务，分属不同业务线，不同时期由不同团队搭建。有的用 Spring Boot，有的用 Dubbo，有的还是老项目。每个服务的 pom.xml 里都塞了一堆依赖，谁也说不清 Log4j 到底被哪些服务直接或间接引用了。
最后怎么解决的？安全团队逼着每个服务的负责人自己去翻 pom.xml，一个一个查。折腾了将近一周，才勉强拉出一份"受影响服务清单"。
然后呢？升级 Log4j 版本，半天搞定。
找漏洞花了一周，修漏洞花了半天。
那天晚上回酒店的路上我就在想：这不对。问题不在于"怎么修"，而在于"去哪找"。如果连自己系统里用了什么都不知道，谈什么安全治理？
后来我见得越多，越确信一件事——这不是某一家银行的问题，几乎所有企业都处于同样的状态：你的软件供应链，实际上是失控的。
你的代码里，大部分不是你写的
后来我做了一个统计，那个银行客户 200 多个微服务的代码仓库里，开源代码占比平均在 70% 以上，有几个老系统甚至超过 85%。
这不是个例。Synopsys 2023 年审计了 1700 多个代码库，发现 96% 的代码库包含开源组件，76% 的代码是开源代码。Veracode 的数据更狠——97% 的 Java 应用完全由开源组件构成。
也就是说，你花了几百人年搭起来的系统，大部分"砖"是别人免费给的。
这本身不是问题，开源组件让软件开发效率提升了不知道多少倍。问题在于——你用了别人的东西，但你不知道你用了什么。
这就像你盖了一栋楼，用了 200 家供应商的材料，但没有任何一份材料清单。有一天有人告诉你"3 号供应商的钢筋有质量问题"，你连这栋楼里哪些地方用了他家的钢筋都查不出来。
这就是所谓的"失控"。
我在项目里见过的三种"失控"场景
场景一：漏洞来了，全公司翻箱倒柜
除了 Log4j，我还经历过好几次类似的事。
有一次，安全团队通报 Fastjson 某个版本存在反序列化漏洞。我们赶紧去排查，发现系统里至少有 30 多个服务用了 Fastjson。但问题是——版本号五花八门，有 1.2.37 的，有 1.2.68 的，还有几个服务用的是 1.1.x 的老古董。
更头疼的是，有些服务不是直接引入的 Fastjson，而是通过某个二方库间接带进来的。开发自己都不知道自己用了 Fastjson。
你让开发一个个去查，效率极低，而且容易漏。漏掉一个，就是一个安全隐患。
你连"有什么"都不知道，怎么防？
场景二：问谁都不知道的"历史遗留"
还有一个场景特别常见。
系统里有个工具类，引用了一个叫 commons-collections 的 Apache 组件。这个组件的某个老版本有反序列化漏洞。我们要不要升级？升级了会不会影响现有功能？
问了三个开发，三个说法不一样：
-
第一个说："这个组件是我前任留下的，我也不知道为什么用这个版本。"
-
第二个说："升级过一次，但是测试环境跑不通，又回滚了。"
-
第三个说："这个类好像没什么地方在用，但不敢删。"
你看，一个组件，三个人三个态度，没有一个人能给出确定答案。最后只能先标记为"风险已知，暂不处理"——说白了就是搁置。
搁置不是解决了，是假装不存在。
场景三：你下载的开源包，可能已经不是原来的了
2024 年出了一个大事件，不知道你关注了没有。
有个叫 xz-utils 的开源项目，是几乎所有 Linux 系统都默认安装的压缩工具。有个叫 Jia Tan 的人，从 2022 年开始给这个项目提交代码补丁，表现得很积极，慢慢获得了项目的维护权限。
然后他在 2024 年发布的 5.6.0 和 5.6.1 版本里，悄悄植入了一个后门。这个后门的目标是什么？劫持几乎所有 Linux 服务器的 SSH 登录。
如果不是微软的一个工程师偶然发现 sshd 登录速度变慢了，顺藤摸瓜查到了 xz-utils 的问题，这个后门不知道会被埋多久。
这事儿细思极恐的地方在于：xz-utils 是一个有十几年历史、被全球无数系统依赖的基础设施级项目。攻击者不是从外面攻破的，而是从内部渗透进去，变成了维护者。
你用的开源组件，可能已经不是原来的那个组件了。但你不知道。
你连"变没变"都感知不到，这叫什么？失控。
靠 Excel 管依赖？别逗了
说完问题，说说很多企业现在的做法。
最常见的是让开发自己报。每次引入新组件，填个表，写明组件名、版本号、用途。听起来很合理对吧？
现实是：开发忙着写业务代码，填表这件事优先级永远排在最后。报上来的信息也不靠谱——版本号写错了、间接依赖没报、升级了忘了更新记录。半年后你去看那份表，跟实际情况已经对不上了。
还有用 Excel 维护的。我见过一个客户，安全团队维护了一份巨大的 Excel 表，记录了所有系统的开源组件信息。但是——
-
系统 A 升级了一个依赖版本，Excel 没更新
-
系统 B 新引入了一个组件，开发忘了报
-
系统 C 重构了，删了几个依赖，没人知道
三个月后，这份 Excel 就成了一份"历史文物"——有记录价值，但没有参考价值。
靠人的主动性和记忆去管理动态变化的依赖关系，注定管不住。
SBOM 解决了什么？首先解决一件事：让你看得见
SBOM，Software Bill of Materials，软件物料清单。
概念不复杂，说白了就是给你的软件出一份"配料表"——里面用了哪些开源组件、什么版本、从哪来的、依赖关系是什么。
但它首先解决的，是可见性的问题——让你看得见你的系统里到底有什么。
还是拿 Log4j 举例。如果每个服务在构建的时候都自动生成了一份 SBOM，存到中央仓库里，那安全团队只需要在系统里搜一下 "log4j"，30 分钟内就能拉出完整的清单：
-
哪些服务用了 Log4j
-
用的是什么版本
-
是直接引入的还是间接依赖带进来的
-
每个服务的负责人是谁
不用翻 pom.xml，不用问开发，不用猜。
审计人员来检查，问："你们系统里用了哪些开源组件？许可证合规吗？"
没有 SBOM 的时候，你得翻历史邮件、找各个团队收集信息、手动整理成表格，搞上好几天，最后还不一定全。
有了 SBOM，一键导出。什么组件、什么版本、什么许可证、谁引入的、什么时候引入的，全部有据可查。
把"不知道"变成"知道"，把"查不到"变成"一键搞定"。
从这个角度看，SBOM 做的事情，本质上不是"列清单"，而是把原本不可见的软件依赖，变成可以被管理的资产数据。
但我要说句实话
SBOM 解决的是"可见性"问题。
但"看得见"只是第一步。
我见过太多企业，做了 SBOM、买了扫描工具、部署了自动化流水线，觉得自己挺现代化了。但开源依赖还是管不好。为什么？
因为看得见不等于管得住。
你看得见系统里有 30 个服务用了 Fastjson，但开发就是不升级，你怎么办？你看得见某个组件的 License 有风险，但业务说"这个功能下周就要上线，来不及换了"，你怎么决策？
可见性是基础，但光有可见性，你的系统依然是失控的。
如果把这件事拆开，其实至少需要三层能力：
-
第一层：可见性——你知道系统里用了什么、有什么风险
-
第二层：控制力——你能管住团队怎么用、出了事怎么处理
-
第三层：决策能力——你知道该不该用、用哪个、什么时候换
SBOM 解决的是第一层。但没有第一层，后面两层都无从谈起。
后面我会一篇一篇展开讲。
不做行不行？看政策
说到这里，可能有人觉得："我们公司目前没出过事，有必要搞这个吗？"
我理解这种想法。但我想说两个事实：
-
2021 年，美国政府发布了总统行政令 EO 14028，要求所有向联邦政府交付的软件必须提供 SBOM。这不是建议，是强制要求。
-
中国也已经发布了 GB/T 47020《网络安全技术 软件物料清单数据格式》国家标准，中国信通院已经启动了 SBOM 国标符合性验证工作。
趋势很明确：SBOM 正在从"最好有"变成"必须有"。尤其是金融、政务这些强监管行业，早晚会面对这个要求。
与其等审计来了临时抱佛脚，不如现在就建起来。
回到那个银行项目
最后说说那个银行项目后来的变化。
我们在交付过程中帮客户建了一套 SBOM 机制：每次 CI 构建的时候自动生成物料清单，推送到中央仓库。所有服务的开源组件信息实时更新，不用人手工维护。
效果很直观：
-
之前安全团队问"系统里有没有用 X 组件"，48 小时答不上来；后来同样的查询，2 小时出结果
-
之前合规审计准备软件成分清单，几个人搞了好几天还经常漏；后来一键导出
-
之前新引入组件没人管，出了事找不到责任人；后来每个组件什么时候引入的、谁引入的、为什么引入，全部有记录
不是什么花哨的技术方案，就是把"看不见"的东西变得"看得见"了。
从失控，到可控的第一步。
但如果只有这一步，你的系统，依然是失控的。
很多人到这里会产生一个错觉："我们已经做了 DevOps，CI/CD 也跑起来了，这些问题应该已经解决了。"
但现实往往正好相反。
下篇预告
下一篇聊聊：
本文来自博客园，作者：lunzi_fly，转载请注明原文链接：https://www.cnblogs.com/lunzi1992/p/19953736