【开源治理·银行篇】06-供应商软件为什么必须交付 SBOM？
系列「金融开源治理实战」第一季 · 银行业
以下场景根据多个银行项目中的共性问题脱敏合并，不对应任何单一机构。
某银行在一套私有化部署软件进入验收前，收到了供应商提供的"开源软件清单"。
清单是一份 Excel，包含组件名称、版本和许可证。采购团队认为供应商已完成交付，安全团队却无法用它完成验证：
- 清单没有标明对应哪个产品版本和安装包。
- 只列了供应商直接引入的库，没有依赖关系和嵌套组件。
- 部分名称是供应商内部简称，无法与公开漏洞库中的身份直接匹配。
- 没有制品哈希、生成时间和生成工具，也无法判断清单是从源码、构建过程还是人工台账整理出来的。
银行对安装包另行扫描后，又发现了清单中没有的成分。供应商解释，那些可能来自基础镜像、商业中间件或定制交付包，需要回到产品团队再核对。但合同里只写了"交付开源软件清单"，没有约定覆盖范围、数据格式、验证方式和更新责任。
这份文件算不算 SBOM，已经不是最紧要的问题。真正的问题是：银行无法用它证明这次实际交付包含什么，也无法据此追踪后续漏洞、License 和停止维护风险。
可以外购软件，不能外包管理责任
上一篇把自研和可获取制品的下载路径收到了内部可信源站。但供应商交付的商业软件、外包代码和私有化产品，往往不是由银行自己从公共上游重新构建。
这类软件的特殊之处在于：
- 供应商控制源码、构建过程和版本升级。
- 银行承担生产运行、数据安全和业务连续性后果。
- 漏洞和停止维护信息即使最先到达银行，修复能力仍然可能在供应商手中。
GB/T 43698---2024 将需方、供方和运营方等不同主体纳入软件供应链安全要求1。NIST SP 800-161 Rev.1 也将供应链风险管理放入产品和服务的获取、使用和维护过程2。这些材料的共同指向不是"所有软件都要提供相同文件"，而是需方必须获得足以支撑风险判断和持续管理的透明度。
SBOM 在这里是一个基础交付物：它让银行可以把"供应商软件有风险"这种模糊担忧，转换成具体的组件、版本、依赖关系和责任边界。
三种供应商软件，交付边界不一样
"供应商软件"不是一个单一对象。如果不先界定交付边界，合同里的 SBOM 很容易变成一句无法验收的原则要求。
| 交付类型 | 银行真正使用的对象 | 容易遗漏的边界 | SBOM 应绑定到什么 |
|---|---|---|---|
| 商业套装软件 | 供应商发布的安装包、补丁或镜像 | 内置运行时、插件、商业中间件和嵌套包 | 具体产品版本、构建号和交付制品哈希 |
| 外包开发或联合开发 | 源码、构建脚本、依赖锁文件和最终制品 | 外包团队的开发环境、子承包方和构建阶段引入的依赖 | 银行实际验收的每个发布制品 |
| 私有化部署产品 | 标准产品、客户定制包、基础镜像和部署组件的组合 | 标准版与定制版的差异，以及部署时才加入的成分 | 最终在本行环境安装或运行的版本组合 |
对 SaaS 或完全托管服务，银行可能无法取得每一个后端制品。这时也不应直接放弃组件透明度，而是要另行约定服务版本或发布周期对应的 SBOM 提供方式、重大漏洞通知、影响分析和独立保证材料。SaaS 的 SBOM 覆盖范围和技术实现方式可以另行约定，但可验证的组件清单、重大漏洞通知、影响定位和补丁责任不能省略。交付方式可以调整，风险信息不能因为服务形态而消失。
合同不要只写"提供 SBOM"
一条可验收的 SBOM 要求，至少要回答交付对象、数据内容、交付时点、验证权利和后续责任五类问题。
供应商 SBOM 交付要求
| 条款主题 | 建议约定的技术内容 | 验收时要看的证据 |
|---|---|---|
| 交付对象 | 产品名称、版本、构建号、交付形态和制品哈希 | SBOM 与实际安装包或镜像能够唯一对应 |
| 覆盖范围 | 直接与传递依赖、编译进制品的组件、插件、运行时、基础镜像及已知未知项 | 覆盖声明、排除项和原因 |
| 数据格式 | 约定 SPDX 或 CycloneDX 等可机器读取格式、规范版本和字符编码 | 文件能通过对应 schema 或规范校验 |
| 最小字段 | 组件和供应商名称、版本、标识符、哈希、许可证、依赖关系、生成工具、时间和生成上下文 | 字段完整性和空值说明 |
| 交付时点 | 测试入场、正式验收、主版本升级、紧急补丁和成分变化时重新交付 | 每个已验收版本都有对应 SBOM 快照 |
| 漏洞与影响通知 | 约定通知窗口、时限、影响版本、可利用性说明、缓解方案和修复计划 | 漏洞通知、VEX 或影响声明、补丁计划 |
| License 与来源声明 | 声明组件许可证、来源和供应商承担的合规责任 | SBOM、许可证文本、第三方声明和差异说明 |
| 验证与纠偏 | 银行有权对实际制品扫描、抽样和差异比对，供应商对经确认的缺失进行解释或更正 | 差异清单、分析结论、更新后的 SBOM |
| 支持与退出 | 升级支持期、停止维护通知、关键组件替换和数据迁移协助 | 支持政策、EOL 通知和退出方案 |
| 保密与使用 | SBOM 的传输、存储、访问、内部分发和对外披露边界；同时约定内部审计、监管检查和依法依规报送时的授权使用机制，不得以一般保密条款阻断必要检查 | 传输记录、访问权限、保密标识和检查/报送授权 |
CISA 2025 年发布的 SBOM 最小要素将哈希、许可证、生成工具和生成上下文等纳入数据字段，同时强调更新频率、覆盖范围、已知未知项和分发交付等实践3。银行可以将它作为设计交付字段的参考，但不应把该文件写成国内金融机构的强制性合规依据。
上表也不是可直接复制的法律条款。技术团队应先把交付和验收条件写清，采购与法务再结合项目类型、合同体系和责任边界形成正式文本。
SBOM 要进入采购和交付流程，不是验收前临时要文件
如果到上线前才第一次向供应商要 SBOM，银行通常只剩两种选择：接受一份无法验证的清单，或者让已经完成部署的项目延期。
SBOM 应在供应商全生命周期中经过以下节点：
| 节点 | 主要动作 | 本节点不合格时如何处理 |
|---|---|---|
| 需求与选型 | 识别软件交付形态、系统重要性和所需组件透明度 | 将无法提供 SBOM 的情况提前纳入供应商风险评估 |
| 招采与合同 | 将交付对象、格式、时点、通知、纠偏和退出要求写入采购文件与合同 | 不允许用口头承诺替代关键交付条件 |
| 测试入场 | 接收初始 SBOM，校验格式、字段和产品身份，尽早发现生成能力缺口 | 退回补正，不等到正式验收再暴露 |
| 交付验收 | 将 SBOM 与实际制品哈希绑定，执行格式校验、制品扫描和差异分析 | 重大差异未解释前不通过该项验收；一般缺失设定补正时限 |
| 上线与资产登记 | 将产品版本、制品、SBOM、部署系统和责任人建立关联 | 无法建立唯一关联时，不能声称该版本已经可追溯 |
| 持续运维 | 根据新漏洞、补丁、组件变化和 EOL 信息更新 SBOM 与影响结论 | 超时未通知或不能定位影响版本时，进入供应商整改和风险升级 |
| 变更与退出 | 主版本、紧急补丁、基础镜像或定制内容变化时交付新快照；停止维护时启动迁移 | 不允许新制品继续沿用旧 SBOM，不允许 EOL 通知只停留在销售联系人邮箱 |
NIST 2026 年发布的 SP 1326 将供应商尽调定义为：调查与供应商或产品相关的可用信息，以支撑新采购或存量系统决策4。这也提醒银行，SBOM 不应只是一次验收材料，而应进入存量供应商的持续评估。
验收 SBOM，要分三层看
一份 SBOM 能被工具打开，不代表它已经可用。比较稳妥的验收方法，是把它分成文件、制品和运营三层。
第一层：文件是否合格
- 是否符合约定的 SPDX、CycloneDX 或其他机器可读规范。
- 必填字段是否完整，组件标识是否可被工具解析。
- 是否说明生成时间、生成工具、覆盖范围和已知未知项。
这一层可以大量自动化，但它只能证明"文件结构合格"。
第二层：是否对应实际制品
- SBOM 中的产品版本、构建号和哈希，是否与验收制品一致。
- 银行独立扫描结果与供应商 SBOM 的差异，是否得到逐项解释。
- 基础镜像、嵌套压缩包、静态链接库、插件和定制模块，是否被纳入或明确排除。
这里不应要求供应商 SBOM 和某一款 SCA 工具结果逐行完全一致。扫描工具可能误识别，供应商清单也可能包含未进入最终制品的构建依赖。验收的关键是差异能否被定位、解释和留痕，而不是追求两份清单表面上一模一样。
第三层：能否支撑后续运营
- 能否用组件标识稳定匹配漏洞和 License 数据。
- 能否快速定位受影响的产品版本、部署系统和责任人。
- 能否与供应商漏洞通知、补丁、风险接受和退出记录建立关联。
CISA 的软件供应链建议将 validation 与 verification 分开：前者关注 SBOM 数据格式是否可以被工具处理，后者关注其内容是否准确反映产品组件5。对银行而言，还要再往前走一步：确认这些数据能否进入本行的资产、漏洞、工单和审计链路。
供应商不能提供完整 SBOM，不要只给"通过"或"不通过"
供应商的情况差异很大：有的是生成能力不足，有的是不愿意直接披露，还有的受到 SaaS 等交付形态限制。对存量商业软件、封闭产品或 SaaS，一开始就要求与银行自研流水线完全相同的 SBOM，可能无法执行。但这不意味着可以把"供应商无法提供"当成风险评估的终点。
| 供应商情况 | 可采取的处理 | 必须保留的底线 |
|---|---|---|
| 可提供完整、机器可读且绑定制品的 SBOM | 进入常规格式、一致性和运营验证 | 版本变化后持续更新 |
| 只能提供直接依赖或部分范围 | 记录缺口，增加银行侧扫描、抽样和供应商整改要求，限制使用范围 | 说明未覆盖范围，不得冒充完整 SBOM |
| 以商业保密为由不愿直接分发 | 通过保密协议、限定人员访问、受控查询或独立第三方验证降低披露风险 | 对重大漏洞、受影响版本和修复计划不能保密为由拒绝回应 |
| SaaS 或无法取得实际制品 | 要求按服务版本或发布周期提供组件透明度、漏洞影响声明和独立保证 | 必须具备重大风险通知、影响定位和持续更新能力 |
| 拒绝提供任何可验证的组件信息 | 结合系统重要性、替代性和补偿控制升级决策，必要时限制准入或不再采购 | 不能因为商业压力将风险默认为已接受 |
有三类问题不宜只用"限期补文件"处理：
- 无法说明 SBOM 对应的产品版本和制品身份。
- 无法建立重大漏洞通知、影响分析和补丁责任。
- 对验收差异拒绝解释，也不接受任何替代验证。
这些问题说明的不只是文档能力不足，而是供应商无法支撑产品进入银行生产环境后的持续风险管理。
交付以后，还要持续验证三类变化
SBOM 验收通过不是终点。供应商软件进入生产后，至少有三类变化会让旧快照失效。
制品变化
主版本、紧急补丁、热修复、基础镜像、插件和定制包发生变化后，都要确认是否形成新制品，并与新 SBOM 快照绑定。
风险信息变化
组件本身不变，新漏洞、License 解释、项目停止维护和上游供应链事件也会改变风险结论。银行需要用现有 SBOM 定位受影响版本，供应商则要提供可利用性判断、补丁和缓解措施。
责任与服务变化
供应商更换产品团队、将模块转交子承包方、缩短支持期或发布 EOL 通知，都会影响原有的处置路径。这类信息应进入供应商台账和组件退出评估，不能只停留在商务沟通中。
持续验证时，银行至少要维持四个稳定关联：
没有这四类关联，即使某次验收时拿到了 SBOM，后面再出现重大漏洞，仍然可能回到逐个项目打电话问供应商的状态。
供应商 SBOM 验收清单
下面这份清单可以作为项目验收的最小底稿：
| 检查项 | 通过条件 | 主要责任 |
|---|---|---|
| 交付对象 | 产品名称、版本、构建号和制品哈希与验收包一致 | 项目验收团队（采购牵头，安全、运维、系统责任人参与） |
| 文件格式 | 符合约定规范，可被工具解析和导入 | 平台/安全团队 |
| 最小字段 | 必填字段完整，空值和未知项有说明 | 平台/安全团队 |
| 覆盖范围 | 直接、传递、嵌套、镜像和定制内容的范围已声明 | 供应商、架构团队 |
| 一致性验证 | 独立扫描与供应商 SBOM 差异已分类、解释和留痕 | 安全团队、供应商 |
| 漏洞与 License | 风险结果已评估，重大问题已有修复、缓解或授权决策 | 安全、法务/合规、系统责任人 |
| 更新与通知 | 联系人、通知时限、更新触发器和补丁责任已确认 | 采购/供应商管理、安全团队 |
| 资产关联 | SBOM 已关联到制品、系统、业务和责任人 | 资产管理、系统责任人 |
| 证据留存 | 原始 SBOM、校验结果、扫描结果、差异说明和审批记录可追溯 | 项目团队、平台运营团队 |
采购团队不需要独自判断 SBOM 是否完整，安全团队也不应独自承担供应商交付责任。采购负责让要求进合同和考核，专业团队负责验证风险信息，系统责任人负责确认交付结果是否满足本系统使用条件。
那份 Excel 最后缺的不是几列字段
回到开篇的项目。如果只让供应商继续补充 Excel 列，下一次版本升级时，同样的争论还会重复。
真正需要改的是交付机制：
- 在采购文件和合同中定义对象、格式、覆盖范围和更新责任。
- 在测试入场时就验证供应商的生成能力，不把问题留到上线前。
- 将每份 SBOM 绑定到实际交付制品，并保留独立扫描与差异分析。
- 在运维阶段持续接收漏洞、补丁、版本和 EOL 信息。
到这一步，SBOM 才从"供应商交了一份文件"变成"银行能够持续管理这个产品的基础数据"。
但即便 SBOM 本身合格，它仍然只是一份关于某个制品快照的记录。要回答某个组件出现风险时影响哪些系统、业务和责任人，还要把它与制品、资产、工单、审批和整改记录连起来。
第 07 篇将继续处理这个问题：银行如何建立可审计的软件供应链证据链。
数据来源
- 国家标准化管理委员会，GB/T 43698---2024《网络安全技术 软件供应链安全要求》，2024。https://std.samr.gov.cn/gb/search/gbDetailed?id=173829859D2E1AA5E06397BE0A0AA311
- National Institute of Standards and Technology, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, NIST SP 800-161 Rev.1, updated 2024. https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final
- Cybersecurity and Infrastructure Security Agency, Minimum Elements for a Software Bill of Materials (SBOM), 2025. https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf
- National Institute of Standards and Technology, Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide, NIST SP 1326, 2026. https://csrc.nist.gov/pubs/sp/1326/final
- Cybersecurity and Infrastructure Security Agency, Securing the Software Supply Chain: Recommended Practices for Managing Open Source Software and Software Bill of Materials, 2024. https://www.cisa.gov/sites/default/files/2024-08/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN RECOMMENDED PRACTICES FOR MANAGING OPEN SOURCE SOFTWARE AND SOFTWARE BILL OF MATERIALS_508.pdf