【开源治理·银行篇】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?id173829859D2E1AA5E06397BE0A0AA311National 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/finalCybersecurity 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.pdfNational 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/finalCybersecurity 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%20RECOMMENDED%20PRACTICES%20FOR%20MANAGING%20OPEN%20SOURCE%20SOFTWARE%20AND%20SOFTWARE%20BILL%20OF%20MATERIALS_508.pdf