夜雨聆风过去二十年，银行业的技术创新高度依赖开源软件。它带来了敏捷迭代、生态丰富和成本优势。然而，Log4j2漏洞事件敲响警钟——一个广泛使用的开源组件出现高危漏洞，会导致全球企业陷入应急泥潭。当此类漏洞爆发时，由于缺乏SBOM（Software Bill of Materials，软件物料清单）管理，无法自动关联漏洞与资产，应急响应只能是“人海战术”式的逐个系统排查，且难以保证全覆盖。本文来自社区同行分享企业SBOM建设现状和趋势，以及相关知识和难点对策。
·来自企业IT应用趋势项目创新联盟 · “开源治理与基础软件选型与收敛”课题方向 | 银行开源治理：创新与安全可控课题
为应对开源漏洞应急响应和供应链安全审查，银行SBOM管理能力的建设现状和选型方向如何？
*投票为社区同行投票的阶段性结果（目前来自34家企业同行），仅供参考，更多结论可参考后续课题报告
技术路线状态：当前得票最多的为【规划/评估中】
在SBOM工具选型中，同行认为更应优先保障【集成与自动化】【生成全面性】
在SBOM格式选择上，同行认为更应优先考虑【行业通用性】
难点一：SBOM应包含哪些最小必要信息（组件名、版本、许可证、依赖关系、漏洞关联）？
SBOM（软件物料清单）的最小必要信息由国际主流标准（如美国NTIA/CISA指南、中国国家标准GB/T 47020—2026）明确定义，核心要素仅包含7项基础字段，无需强制包含漏洞详情（漏洞需通过外部数据库关联）。以下内容基于当前有效标准提炼，重点关注必要性、时效性与权威性：
一、最小必要信息的7项核心要素
根据美国CISA《2025软件物料清单最低要素》及中国国家标准GB/T 47020—2026，SBOM必须包含以下7项不可省略的基础信息：
1、组件基础标识信息
组件名称（Component Name）：供应商定义的软件单元名称（如log4j-core），必须唯一标识组件本身。
版本字符串（Version）：供应商用于区分更新的版本号（如2.17.1），直接影响漏洞匹配准确性。
唯一标识符（Unique Identifier）：采用标准化格式（如PURL、CPE或SWID Tag ID），确保全球无歧义定位组件。例如：
pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1。
2、供应链关系信息
依赖关系（Dependency Relationship）：明确组件间的直接依赖（如A依赖B），必须包含传递性依赖（间接依赖），否则无法完整追溯风险路径。
3、责任与时间信息
供应商/作者（Supplier/Author）：组件的创建者或当前维护者（如The Apache Software Foundation），用于责任追溯。
SBOM生成者（Creator of SBOM）：生成SBOM的组织或个人（需提供联系信息）。
时间戳（Timestamp）：SBOM的生成或更新时间（必须采用UTC格式），确保时效性可验证。
二、关键澄清：许可证与漏洞关联的定位
1、许可证信息（License）属于最小必要项
许可证字段（如Apache-2.0）是最小必要信息的一部分，用于合规性管理，但需注意：
仅需声明直接关联的许可证，无需展开详细条款。
若组件含多许可证，需明确标注组合逻辑（如GPL-2.0-only OR Apache-2.0）。
2、漏洞信息不属于SBOM最小必要内容
漏洞详情（如CVE编号、严重等级）并非SBOM的直接组成部分，而是通过以下方式关联：
SBOM提供唯一标识符（PURL/CPE），供外部工具（如CVE数据库）自动匹配漏洞。
漏洞状态管理需依赖VEX（漏洞可利用性交换）文件，作为SBOM的独立补充文档。
强制要求SBOM包含实时漏洞数据会导致时效性失效（漏洞库动态更新，SBOM需静态存档）。
三、常见误区与标准演进
1、必须规避的错误认知
误区：将SBOM等同于漏洞报告（如要求直接列出CVE）。
正解：SBOM是成分清单，漏洞需通过标准化标识符关联外部数据库。
误区：仅记录直接依赖（忽略传递性依赖）。
正解：传递性依赖必须完整纳入，否则无法覆盖Log4j类漏洞的深层传播路径。
2、标准动态与合规要求
中国国家标准GB/T 47020—2026（2026年8月1日实施）与CISA 2025指南高度一致，最小要素仍为上述7项。
欧盟CRA法案（2027年全面生效）要求SBOM支持机器可读格式（SPDX/CycloneDX），但不新增最小字段。
AI/ML场景扩展：SPDX 3.0和CycloneDX 1.6新增AI Profile/ML-BOM，但仍以基础7项为最小集，扩展内容属可选。
总结
SBOM的最小必要信息是7项基础字段（组件名、版本、唯一标识符、依赖关系、供应商、生成者、时间戳），许可证属于必要项，漏洞信息需通过外部关联实现。企业实施时应优先确保这7项的完整性与准确性，再根据场景扩展VEX或AI-BOM等模块。当前国际标准（CISA 2025、GB/T 47020—2026）均未将实时漏洞数据纳入最小要求，避免因动态更新导致SBOM失效。
难点二：SBOM如何与现有CI/CD流水线、资产管理系统集成？
SBOM与现有CI/CD流水线、资产管理系统的全流程集成落地，实现软件供应链标准化、自动化治理。在CI/CD研发流水线中，我们将SBOM生成能力嵌入应用构建环节，通过CycloneDX、Syft工具自动对源码、容器镜像生成标准化物料清单，并统一归集至SBOM管理平台。同时配置流水线安全门禁，对高危漏洞、违规许可证等风险进行拦截，从研发源头杜绝不安全组件发布上线，实现安全左移管控。
在资产管理层面，依托SBOM平台标准化API接口，实现与CMDB、SAM资产系统的数据打通，自动同步各业务应用的组件版本、开源依赖、授权协议及关联漏洞信息，补齐了传统资产台账缺失的底层软件依赖明细，大幅提升软件资产盘点准确率。
最终形成完整治理闭环，资产侧监测到的漏洞风险可反向推送至研发侧完成整改修复，应用版本迭代更新后，流水线将自动刷新SBOM数据，并同步更新资产管理台账，实现软件资产、安全风险、版本迭代的动态联动管理。
难点三：采购合同中应要求供应商提供哪些开源治理承诺（如SBOM交付、漏洞修复时限）？
为有效管控开源软件引入风险，通常会在采购合同中明确要求供应商提供配套的开源治理承诺文件，以此作为合同附件，与主合同具有同等法律效力。具体而言，我们主要会要求供应商提供《供应商开源安全承诺书》或《软件供应链安全附件》等标准化文本，承诺相关内容：
第一，供应商须保证所交付软件中所有开源组件均符合合规性要求，尤其不得存在开源许可证冲突或兼容性问题。
第二，在软件物料清单（SBOM）交付方面，供应商须在交付软件的同时提供符合行业标准格式（如SPDX、CycloneDX）的详细SBOM，清晰列出所有直接和间接的开源依赖项及其版本信息。
第三，针对开源漏洞风险，供应商必须承诺建立与银行安全策略相匹配的漏洞应急响应机制。
此外，我们还会要求供应商承诺在软件生命周期内持续履行上述义务，并保留我行或其指定的第三方对供应商履行开源安全承诺情况进行审计的权利。
支持社区支持本文同行观点，请点赞、转发或点击“♡”
欢迎点击文末阅读原文，可以直接看到社区中本文中可能不包括的的全部信息和最新更新
本内容属于以下课题，欢迎参与交流，了解更多可点击↓↓↓
银行开源治理：创新与安全可控难点攻坚【课题活动 | 欢迎加入我们】
*本公众号所发布内容仅代表作者观点，不代表社区立场
点击下方↙↙↙阅读原文，更丰富，更精彩