SBOM从可选到强制:全球软件监管进入“配料表时代”(2026更新版)

2026年4月7日，我在翻阅相关报道时，注意到834号令已于3月31日正式生效——《国务院关于产业链供应链安全的规定》，我国首部产业链供应链安全专项行政法规，18条，自公布之日起施行。

说实话，这个时间节点太微妙了。就在834号令生效前两个多月，欧盟《网络韧性法案》（CRA）的关键合规倒计时已经开始滴答作响；就在834号令生效前几天，白宫刚刚再次修订了政府供应商的软硬件安全证明要求。

东西方，几乎同步按下了“供应链安全强制执行键”。

这不是巧合，这是信号。

834号令的第12条这样写道：“企业、科研机构等应当完善风险防控体系，实现核心技术及相关信息系统、数据的安全可控。”这句话看起来是宏观的政策语言，但落到软件治理的实操层面，它的含义非常具体：你必须清楚地知道自己的软件系统里装了什么，从哪来，有没有风险，能不能管控。

而这，正是SBOM（软件物料清单）要解决的核心问题。

在我上一篇文章里，我梳理了全球SBOM监管的趋势，以及金融机构落地实践的六大挑战。但834号令的出台，让我觉得有必要做一次更新——因为这一次，中国监管的态度已经从“原则性要求”升级为“专项立法”，软件供应链安全的“中国时间表”正在变得清晰。

今天这篇文章，是对上一篇的更新和补充，核心是回答一个问题：在834号令落地之后，金融机构的SBOM工作应该怎么看、怎么做？

📌 更新导航（写给看过上一篇的朋友）本次主要更新了两处：① 监管章节新增“中国：首部专项立法”一节，重点解读834号令第12条及其对SBOM落地的影响；② 应对策略和结尾部分补充了834号令带来的新变量。 SBOM本质、落地困境（国泰金控六大挑战）、金融机构三重压力这三章内容与上一篇基本一致，熟悉的朋友可直接跳到「应对策略：834号令之后，怎么做？」。

监管转向：从指导到强制的四重信号

如果说上一篇文章写的是“全球监管正在转向”，那这一次，转向已经完成了一半——欧盟和中国都已经完成了专项立法，美国的监管细则也在持续收紧。

欧盟：罚款1500万欧元的“强制令”

（上一篇已对欧盟CRA有详细拆解，这里只更新关键时间节点。）

2024年12月10日，欧盟《网络韧性法案》（CRA）正式生效，设置了两个关键时间节点：

• 2026年9月10日：漏洞和安全事件报告义务开始强制执行
• 2027年12月10日：所有核心安全要求及合规义务全面强制执行

所有在欧盟市场销售的“具有数字元素的产品”，都必须提供SBOM。违规代价：最高1500万欧元，或前一年度全球年营收的2.5%，甚至直接被禁止在欧盟市场销售。

欧盟这次不是建议，而是给了一张“倒计时罚单”。

美国：从“静态清单”到“动态数据源”

（上一篇已梳理了美国从第14028号行政令到CISA要求的演进脉络，这里重点标注最新动态。）

美国的监管路径更微妙。2021年，拜登签署第14028号行政令回应SolarWinds供应链攻击，当时的要求还比较温和：联邦政府采购软件时，供应商“应该”提供SBOM。

但2025年8月，CISA发布了《2025年SBOM最低要素》草案征求意见稿，这个文件标志着监管思路的质变——SBOM不再只是“列出组件的静态清单”，而是要成为“持续监控的动态数据源”。具体要求包括组件哈希值、许可证信息、工具名称和生成上下文，以及必须基于SPDX或CycloneDX等开放标准的机器可读性。

这些要求看似技术细节，实则是在倒逼企业建立“软件供应链持续健康检查”机制。

中国：首部专项立法，软件安全可控有了法律依据

这是本次更新最重要的新内容。

在834号令之前，中国在软件供应链安全领域的监管框架是“拼图式”的——《数据安全法》管数据，《网络安全法》管网络，《关键信息基础设施安全保护条例》管基础设施，但没有一部法规专门针对“产业链供应链安全”这个整体。

834号令填上了这块空白。

作为我国首部产业链供应链安全专项行政法规，834号令建立了多项制度体系，包括关键领域清单制度、风险监测预警制度、应急管理制度等。但对金融机构的软件治理来说，最值得关注的是第12条：

“企业、科研机构等应当完善风险防控体系，实现核心技术及相关信息系统、数据的安全可控。”

这句话的分量，不在于它多具体，而在于它的法律层级——这是国务院行政法规，直接法律效力，不是部门规章，不是指导意见。

你可能会说：这条要求很笼统，“安全可控”到底怎么算？

这正是SBOM的价值所在。你连自己的系统里用了哪些开源组件、这些组件有没有已知漏洞、供应商是谁都说不清楚，谈何“安全可控”？SBOM是实现第12条法律义务的基础工具，这个逻辑是成立的。

更值得注意的是，834号令还有一层背景：它的出台，直接动因是应对部分西方国家的“脱钩断链”和“长臂管辖”。这给SBOM的意义增加了一个新维度——不只是安全合规的工具，更是供应链自主可控的底层基础设施。当你能清晰地看到每一个软件组件的来源，你才能真正评估：哪些依赖存在“断供风险”？哪些核心系统需要国产替代？

全球同步：不是个例，是共识

与此同时，英国、日本、加拿大、澳大利亚、印度均已将SBOM纳入监管框架，美国FDA在医疗器械领域已强制要求提交SBOM。

东西方，真的同步了。软件供应链攻击已经从“偶发风险”变成了“系统性威胁”，监管从“指导性”转向“强制性”，没有例外。

SBOM本质：给软件贴上“溯源码”

先给不太了解SBOM的朋友解释一下，这到底是个什么东西。

你去超市买食品，包装上有配料表，写着“面粉、白糖、食用油、食品添加剂”。但传统的配料表有个关键问题：它只告诉你用了什么，不告诉你这些原料的健康状况——面粉是哪个厂生产的？白糖有没有超标？食用油是不是地沟油？

传统的软件交付就是这样。你拿到一个软件产品，可能知道它用了哪些开源组件（比如Spring框架、Log4j日志库），但你不知道：

• 这些组件是什么版本？
• 有没有已知的安全漏洞？
• 使用的开源协议是什么？（有些协议有“传染性”，可能导致你的核心代码被迫开源）
• 这些组件又依赖了哪些“子组件”？（依赖的依赖，往往才是风险爆发点）

SBOM（Software Bill of Materials，软件物料清单）就像是“带溯源码的配料表”：它不仅告诉你软件用了哪些组件，还会记录每个组件的版本、依赖关系、已知漏洞、开源许可证等关键信息。当某个组件爆出安全问题，你能立刻知道自己的产品有没有用到，用在哪里，影响范围多大。

现在再回头看834号令的第12条——“实现核心技术及相关信息系统、数据的安全可控”——你会发现，没有SBOM，这个要求就缺少落地的抓手。

两大主流格式：SPDX vs CycloneDX

目前全球主流的SBOM格式有两种：

SPDX（Software Package Data Exchange）：由Linux基金会主导，符合ISO/IEC 5962：2021国际标准，支持多种格式（JSON、RDF、标签/值），更注重合规和法律信息。

CycloneDX：由OWASP基金会维护，轻量级，专注于安全用例，更新迭代快（最新版本为v1.7，已于2025年12月成为ECMA国际标准），金融行业用得比较多。

对金融机构来说，选哪种格式不是最重要的，重要的是“机器可读”这个核心能力——SBOM不是给人看的Word文档，而是能被自动化工具扫描、分析、持续监控的结构化数据。

衍生标准：监管已在为未来风险布局

更值得注意的是，SBOM已经衍生出了针对新兴技术的专门标准：

• AIBOM（AI资产清单）：记录AI模型来源、训练数据集、算法、风险评估、伦理风险等。欧盟AI法案已要求高风险AI系统建立完整AIBOM。
• CBOM（加密资产清单）：记录加密算法、密钥管理、证书信息等，应对后量子时代的加密风险。

在834号令“自主可控”的框架下，AIBOM和CBOM的意义格外突出——你引入的AI模型是什么来源？训练数据有没有境外数据污染风险？加密算法有没有被替换的可能？这些问题，都需要有对应的“清单”来回答。

监管不只在解决当下的问题，还在为未来的风险提前布局。

落地困境：国泰金控的六大挑战

理解SBOM是什么容易，但真正落地实施，难度完全是另一个量级。

国泰金控作为金融行业开源治理的先行者，在实践中总结出了六大挑战，我觉得特别有参考价值：

1. 供应商配合度：第三方软件没SBOM怎么办？

这是最现实的问题。你的系统可能用了几十个第三方商业软件，但供应商根本不提供SBOM，或者提供的SBOM质量很差（信息不全、格式不标准）。

目前比较现实的做法是：在新签采购合同时明确要求供应商提供SBOM；对存量软件，用扫描工具“逆向生成”（但准确率有限）；建立供应商分级管理，核心系统的供应商必须提供，边缘系统可以暂时豁免。

834号令生效后，这个谈判筹码变重了。把834号令第12条的合规压力直接传导给供应商——“你帮我们落地安全可控，也是在帮你自己规避合规风险”，比单纯说“我们内部有规定”要有力得多。

2. 工具不成熟：扫描不准、误报多

现有的SBOM生成工具（比如Syft、SPDX-SBOM-Generator等）在扫描复杂依赖关系时，经常会出现漏报、误报、版本混乱的问题。结果呢？生成的SBOM“看起来很完整，但实际上不可信”。

解决这个问题需要工具组合使用（多个工具交叉验证）、人工复核（至少在初期阶段），以及持续优化规则库。

3. 格式不统一：SPDX和CycloneDX转换成本

你的客户要求SPDX格式，你的内部工具链生成的是CycloneDX格式，供应商提供的又是另一种格式。格式转换不仅有成本，还可能丢失信息。

中国正在推进首个数字供应链SBOM格式DSDX，但目前企业实践还在起步阶段，国际互认也是个问题。

4. 隐私问题：SBOM暴露架构细节

SBOM本质上是你的软件“配料表”，里面包含了架构设计、技术选型、依赖关系等敏感信息。如果这些信息泄露给竞争对手，或者被黑客利用来精准攻击，怎么办？

国泰金控的做法是建立分级SBOM：给监管机构的是完整版，给客户的是简化版；同时使用加密和访问控制，将SBOM存储在SBOM Hub中，严格控制访问权限。

5. CI/CD整合：敏捷开发中如何即时生成

金融机构现在都在推敏捷开发，一天可能要发布几十次版本。国泰金控的做法是把SBOM生成集成到CI/CD流程中：代码提交→自动扫描→生成SBOM→上传到SBOM Hub→版本控管，并结合AI方案实现异常告警、自动排列漏洞修补优先顺序。

但这需要对现有CI/CD流程进行大规模改造，初期投入不小。

6. 成本与人才：金融机构普遍缺开源治理人才

实施SBOM机制不只是买个工具那么简单，它需要建立OSPO（开源项目办公室）统筹全集团的开源治理，建立OSRB（开源审查委员会）集结治理、资安、法务和开发团队专家，还需要培养既懂开源技术又懂合规要求还懂金融业务的复合型人才。

国泰金控的OSPO体系建设花了好几年，这个投入对大多数中小金融机构来说是个不小的挑战。

这六大挑战，哪一个都不是买个工具就能解决的。它需要的是一套系统性的组织能力。

金融机构的三重压力

说了这么多，你可能会问：为什么金融机构要率先搞SBOM？其他行业不也面临同样的问题吗？

确实，但金融机构面临的压力是三重叠加的：

压力一：监管最严苛

834号令生效之前，金融机构在供应链安全领域已经要应对《数据安全法》《网络安全法》《关键信息基础设施安全保护条例》，以及欧盟CRA、美国SEC的网络安全披露要求（重大网络安全事件须在4个工作日内披露）。

834号令的落地，让这份压力清单再次加码。更关键的是，834号令第3条明确将金融管理部门列为产业链供应链安全工作的责任部门之一——这意味着监管机构自己也承担了供应链安全的监管职责，金融机构被穿透检查的可能性只增不减。

监管密度和处罚力度，都是最高等级的。

压力二：业务不能停

电商系统崩了，用户大不了改天再买。但银行核心系统如果因为供应链漏洞被攻击，可能导致全国支付瘫痪。金融机构的系统7×24小时运行，这意味着漏洞修补的窗口期极短，必须在不停机的情况下完成安全加固，还需要对依赖关系有极其清晰的掌握——哪些系统用了有问题的组件？影响范围多大？

没有SBOM，这些问题根本无法快速回答。

压力三：技术债最复杂

金融机构的IT系统有个特点：遗留系统特别多。20年前的COBOL代码还在运行，同一个系统里Java、C++、Python、.NET混用，几百个供应商的软件拼接在一起，依赖关系复杂到没人能完全理清。

在这种情况下实施SBOM，难度是互联网公司的好几倍。

但也正因为如此，金融机构成为了全球SBOM实践的“探路者”。我们趟过的坑、总结的经验、建立的标准，会逐渐成为整个行业的参考。

应对策略：834号令之后，怎么做？

说了这么多问题和挑战，那到底应该怎么办？结合834号令落地这个新背景，给不同角色提几点具体建议。

834号令带来了一个新变量：SBOM不再只是“技术团队自己的事”，它被纳入了国务院行政法规的“安全可控”要求，合规压力从技术层传导到了管理层和供应链。这意味着推进SBOM工作的路径和节奏，都需要重新评估一遍。

如果你是技术管理者

第一步：立即启动SBOM试点

不要等到监管来检查才动。选1-2个关键系统（比如核心交易系统、客户数据平台），先把SBOM机制跑通。重点验证：现有工具链能否生成SBOM？生成的SBOM质量如何？能否集成到CI/CD流程？

第二步：评估供应商能力，把SBOM要求写进合同

梳理所有第三方软件供应商，按重要性分级：核心供应商立即要求提供SBOM，作为续约条件；重要供应商在下次续约时加入SBOM要求。

834号令生效后，这件事的推进逻辑变了——不是“我们公司要求你做”，而是“国务院行政法规要求安全可控，你作为我们的供应商，有义务帮助我们满足这一要求”。把合规压力传导给供应链，效果比单纯的内部要求要好得多。

如果你是合规人员

动作一：把834号令纳入监管合规地图

把欧盟CRA、美国行政令14028、中国834号令的具体条款整理出来，标注关键时间节点。中国这条线重点关注两件事：第12条的“安全可控”如何落地证明，以及金融管理部门后续可能出台的配套细则。

动作二：在采购合同中增加SBOM条款

具体可以这样写：

• “供应商应提供符合SPDX或CycloneDX标准的SBOM”
• “SBOM应包含所有开源组件的版本、已知漏洞、许可证信息”
• “供应商应在发现安全漏洞后24小时内更新SBOM”

动作三：建立SBOM审核流程

确定谁来审核、审核什么内容、不符合要求怎么处理。这个流程一旦建立，就是834号令第12条“完善风险防控体系”的直接证明材料。

如果你是开发者

三个实用动作：

学习SBOM格式：花半天时间了解SPDX或CycloneDX的基本结构，知道里面有哪些字段、代表什么含义。

集成SBOM生成工具到CI/CD：推荐几个开源工具——Syft（适合Docker镜像扫描）、SPDX-SBOM-Generator（支持多语言）、CycloneDX Maven Plugin（Java项目专用）。

养成“依赖透明”的开发习惯：引入新依赖前先查有没有已知漏洞；定期更新依赖到最新稳定版本；避免使用停止维护的组件；记录为什么选择某个组件，方便后续审计。

写在最后：不只是透明，还要可控

上一篇文章，我用“透明度革命”来形容SBOM强制化背后的本质。

这一次，834号令给这场革命加了一个新的维度：不只是透明，还要可控。

透明是手段，可控是目的。欧盟要求透明，是为了让市场有监督能力；美国要求透明，是为了让联邦政府的供应链可追溯；中国的834号令要求透明，背后还有一层更深的逻辑——在“脱钩断链”的地缘背景下，你必须知道自己的核心系统依赖了哪些境外技术，这些依赖一旦断供，后果是什么，替代路径在哪里。

这让SBOM的意义，从一个“安全合规工具”，升维成了“数字主权的底层基础设施”。

软件行业也正在经历从“随便用”到“可追溯、可管控、可替代”的转变。

对金融机构来说，我们既是这场变革压力最大的一群人，也是实践最前沿的探路者。834号令落地，不是终点，是起点。接下来，金融管理部门的配套细则、关键领域清单的具体内容、国产替代的评估要求……每一步，都需要有人先走。

我们今天趟过的坑、建立的标准、总结的经验，会逐渐成为整个行业的参考。

而这，才是SBOM强制化背后，最本质的价值。