医疗器械SBOM软件物料清单全球合规指南：FDA、EU CRA与NMPA要求深度解析

在医疗器械日益"软件化"的今天，一台现代化的医疗设备可能包含数百个软件组件——从操作系统内核到加密库，从开源框架到第三方中间件。当其中任何一个组件存在安全漏洞时，整个设备乃至依赖它的医疗网络都可能面临灾难性风险。SBOM（Software Bill of Materials，软件物料清单）正是解决这一"软件供应链黑箱"问题的核心工具，也已成为全球医疗器械监管的强制性要求。

本文将从SBOM的基本概念出发，系统解读美国FDA、欧盟CRA、中国NMPA三大监管体系对SBOM的具体要求，对比SPDX、CycloneDX、SWID三大格式标准，介绍主流生成工具与自动化工作流，并为中国医疗器械企业提供一份可落地的SBOM合规实操指南。

一、什么是SBOM？为什么医疗器械必须重视？

1.1 SBOM的定义

SBOM（Software Bill of Materials，软件物料清单）是对软件产品中所有组件、库、模块及其依赖关系的一份正式、结构化的清单。如果将软件比作一道菜，SBOM就是这道菜的完整配料表——不仅列出了每种"配料"（组件）的名称和版本，还说明了它们的来源、许可证类型和相互关系。

SBOM的概念最早由美国国家电信和信息管理局（NTIA）在2021年通过行政命令EO 14028《改善国家网络安全》正式推动。NTIA定义了SBOM的最低必备要素（Minimum Elements）：

要素类别	具体字段	说明
数据字段	供应商名称（Supplier Name）	组件的创建者或分发者
数据字段	组件名称（Component Name）	软件组件的正式名称
数据字段	组件版本（Version）	精确的版本标识符
数据字段	唯一标识符（Unique Identifier）	如CPE、PURL或SWID Tag ID
数据字段	依赖关系（Dependency Relationship）	上游/下游组件的关联关系
数据字段	SBOM作者（Author）	生成该SBOM的实体
数据字段	时间戳（Timestamp）	SBOM的创建或更新时间
实践要求	自动化生成	支持机器可读格式的自动化SBOM生成
实践要求	频率与深度	每次构建或发布时更新，覆盖所有已知组件
实践要求	已知未知处理	明确标注分析中未能识别的区域

1.2 医疗器械为何必须关注SBOM

医疗器械软件的特殊性在于：一旦被攻击，后果直接威胁患者生命安全。以下案例说明了软件供应链透明度的紧迫性：

案例一：Log4Shell漏洞（CVE-2021-44228）

2021年12月，Apache Log4j开源日志库曝出史上最严重漏洞之一。由于Log4j被广泛嵌入到各种Java应用中，全球大量医疗器械和医院信息系统受到波及。FDA与CISA联合发布紧急通知，要求制造商紧急排查其产品中是否使用了受影响的Log4j版本。然而，大多数制造商无法迅速回答"我的产品里到底有没有Log4j"这个简单问题——因为他们没有SBOM。

案例二：SolarWinds供应链攻击（2020）

攻击者通过在SolarWinds Orion平台的构建流程中植入恶意代码，影响了约18,000个组织，包括多家医疗机构。这次攻击证明：即使是可信的商业供应商提供的软件，也可能在不知情的情况下成为攻击载体。

案例三：WannaCry勒索攻击（2017）

WannaCry利用Windows SMB协议漏洞在全球范围内传播，英国NHS系统遭受重创，超过80家医疗机构的诊疗活动被迫中断。大量医疗器械运行在未打补丁的Windows版本上，制造商缺乏对软件组件的系统性管理是核心原因之一。

案例四：Medtronic胰岛素泵安全漏洞（2019）

美国FDA对Medtronic MiniMed系列胰岛素泵发布紧急召回通知，因其无线通信协议存在漏洞，攻击者可能远程篡改胰岛素输注剂量。这一事件直接推动了FDA对联网医疗器械网络安全要求的强化。

这些事件的共同教训是：如果制造商不知道自己的产品中包含哪些软件组件，就无法在漏洞被发现时做出快速响应。SBOM正是填补这一信息鸿沟的基础设施。

1.3 SBOM在医疗器械生命周期中的价值

阶段	SBOM的价值
设计开发	识别高风险依赖、避免引入已知漏洞组件
注册送审	满足FDA/NMPA/EU CRA的强制提交要求
生产制造	确保构建环境与审批版本一致
上市后监控	当新漏洞（CVE）发布时，快速评估影响范围
补丁管理	精确定位需要更新的组件，制定补丁策略
退市/报废	识别仍在使用中的遗留组件风险

1.4 SBOM与SOUP/OTS的区别与联系

对于熟悉IEC 62304的医疗器械软件工程师来说，SOUP（Software of Unknown Provenance，来源不明的软件）是一个耳熟能详的概念。许多中国企业已经在日常开发中维护SOUP清单，那么SBOM与SOUP到底有什么关系？是否可以用SOUP清单替代SBOM？

核心概念辨析：

首先需要厘清三个常见术语的定义与边界：

术语	标准来源	定义	典型内容
SOUP (Software of Unknown Provenance)	IEC 62304:2006/AMD1:2015	已开发且非本设备软件制造商开发目的的软件项，或制造商对其开发过程没有充分知悉的软件项	开源库、第三方SDK、商业中间件
OTS/COTS (Off-the-Shelf / Commercial Off-the-Shelf)	FDA指南 / IEC 62304	在不改变其设计的情况下集成到医疗器械中的已存在软件	操作系统、数据库引擎、商业加密库
SBOM (Software Bill of Materials)	NTIA / IMDRF N73 / FDA 524B	对软件产品中所有组件及其关系的正式、结构化、机器可读的完整清单	自研代码 + SOUP + OTS + OS + 所有传递依赖

关键区别：SOUP和OTS都是IEC 62304框架下的软件分类概念，主要服务于内部风险管理和软件开发过程控制。SBOM则是一个更广泛的网络安全透明度工具，它不区分组件的来源分类，而是追求对软件组成的完整可见性，并以机器可读格式向外部利益相关者共享。

SOUP/OTS vs SBOM详细对比：

维度	SOUP/OTS（IEC 62304）	SBOM
来源标准	IEC 62304:2006/AMD1:2015	NTIA Minimum Elements / IMDRF N73 / FDA 524B
核心目的	内部风险管理——评估和控制外部软件组件引入的风险	外部透明度——向监管机构、医疗机构和供应链伙伴提供软件组成的可见性
覆盖范围	仅覆盖"来源不明"或"现成"的外部软件（不包括自研代码）	覆盖所有软件组件，包括自研代码、开源、商业和操作系统组件
文档形式	通常为内部文档（Word/Excel），不要求机器可读	必须机器可读（SPDX/CycloneDX格式）
共享对象	内部研发和质量团队	监管机构、医疗机构、供应链合作伙伴
漏洞关联	要求进行风险评估，但不要求关联CVE数据库	要求关联已知CVE，并提供VEX声明
更新频率	设计变更时更新	每次构建/发布时自动更新
依赖深度	通常仅记录直接集成的SOUP项	要求覆盖传递依赖（transitive dependencies）
唯一标识	无强制要求	要求CPE或PURL等标准唯一标识符

如何从SOUP清单过渡到SBOM：

对于已经维护SOUP清单的中国企业，SBOM合规并非从零开始——SOUP清单是SBOM的一个重要子集。推荐的过渡路径：

盘点现有SOUP清单：将现有SOUP记录作为SBOM的基础数据源
补充自研组件：SOUP清单不包含自研模块，SBOM需要将其纳入
补充操作系统和驱动组件：许多SOUP清单忽略了OS层面的组件
解析传递依赖：SOUP清单通常仅记录直接引入的组件，SBOM要求递归覆盖传递依赖
添加唯一标识符：为每个组件补充PURL（Package URL）或CPE标识
格式转换：将Excel/Word格式的SOUP清单转换为CycloneDX或SPDX机器可读格式
添加CVE关联：使用SCA工具自动匹配组件版本与已知漏洞
建立自动化流程：将手动维护的SOUP清单升级为CI/CD自动生成的SBOM

SOUP与SBOM的数据映射示例：

SOUP清单字段	对应的SBOM字段	需要补充的信息
组件名称	Component Name	标准化命名（避免大小写和缩写不一致）
版本号	Version	精确到补丁版本号
供应商/项目	Supplier Name	使用标准化供应商名称
功能描述	—	SBOM无强制要求，但有助于审评理解
风险评估结果	—	SBOM不直接包含，通过VEX文档关联
—	Unique Identifier (PURL)	SOUP清单通常缺失，需补充
—	Dependency Relationship	SOUP清单通常不记录，需通过SCA工具生成
—	License	SOUP清单可能记录，但格式需标准化（使用SPDX License Identifier）

关键认识：SOUP清单是IEC 62304风险管理框架下的内部文档，SBOM则是网络安全透明度框架下的外部共享文档。两者并非替代关系，而是互补关系——企业应当同时维护SOUP清单（用于内部风险管理）和SBOM（用于外部合规与透明度），并确保两者数据的一致性。对于同时需要通过IEC 62304审核和提交SBOM的企业，建议以SBOM为"唯一数据源"（Single Source of Truth），从SBOM中自动导出符合IEC 62304要求的SOUP清单，避免两套文档之间的数据不一致问题。

二、FDA SBOM要求：从推荐到强制的里程碑

2.1 法律基础：FD&C Act第524B节

2022年12月，美国国会通过《综合拨款法案》（Consolidated Appropriations Act, 2023），其中包含被称为"PATCH Act"的条款，在《联邦食品、药品和化妆品法案》（FD&C Act）中新增了第524B节——"确保网络设备安全"（Ensuring Cybersecurity of Devices）。这是全球范围内首次以立法形式要求医疗器械SBOM提交的里程碑事件。

第524B节的核心要求：

SBOM强制提交：所有"网络设备"（Cyber Device）的上市前申请（510(k)、De Novo、PMA）必须包含SBOM
安全更新计划：制造商必须提交上市后网络安全监控与漏洞修补计划
协调漏洞披露：制造商必须建立协调漏洞披露（CVD）流程
安全补丁与更新：在产品的整个生命周期内提供安全补丁和更新

如需了解FDA网络安全要求的完整框架，请参阅我们的深度解读：FDA医疗器械网络安全合规指南。

2.2 FDA网络安全最终指南中的SBOM细则

2025年6月，FDA发布了《医疗器械网络安全：质量体系考量与上市前提交内容》最终指南（Final Guidance），2026年2月进一步发布修订版（长达60页），将网络安全纳入质量管理体系框架（与ISO 13485:2016对齐），并对SBOM要求进一步细化：

SBOM涵盖范围：

组件类型	是否纳入SBOM	FDA关注点
自研软件（Proprietary）	必须	版本控制、变更历史
商业现成组件（COTS/OTS）	必须	供应商名称、版本、EOL/EOS状态
开源组件（Open Source）	必须	许可证合规、已知CVE、社区活跃度
操作系统与驱动程序	必须	安全支持状态、补丁策略
云端/后端服务组件	必须	SaaS类SaMD需涵盖服务器端SBOM
编译器/构建工具	建议	非必须，但有助于供应链完整性

SBOM格式要求：

FDA在最终指南中明确推荐使用以下机器可读格式：

SPDX（Software Package Data Exchange）—— 由Linux基金会维护的ISO/IEC 5962:2021国际标准
CycloneDX —— 由OWASP维护的SBOM标准，在安全场景中使用广泛

FDA强调：SBOM必须是机器可读的（machine-readable），不接受Excel表格、PDF列表或Word文档等非结构化格式。

SBOM数据深度要求：

要求层级	说明	FDA期望
顶级组件（Top-Level）	直接集成到设备中的组件	必须完整列出
传递依赖（Transitive Dependencies）	组件的依赖项的依赖项	必须覆盖到"已知合理"的深度
已知漏洞（Known Vulnerabilities）	组件中存在的已知CVE	必须列出并提供风险评估
组件支持状态	EOL（End-of-Life）和EOS（End-of-Support）信息	必须标注，并提供不受支持组件的风险缓解措施

2.3 RTA（拒绝受理）风险

自2023年10月起，FDA已开始对缺少SBOM的网络设备申请执行RTA政策。根据FDA公开数据和行业反馈：

常见SBOM缺陷	RTA风险等级	补救措施
未提交SBOM	极高	补充SBOM后重新提交
仅提交Excel/PDF格式	高	转换为SPDX或CycloneDX格式
未覆盖传递依赖	中高	使用SCA工具重新扫描，补全依赖树
未包含已知CVE评估	中	进行漏洞扫描并添加风险评估
未标注EOL/EOS组件	中	确认组件支持状态并更新SBOM
SBOM版本与提交软件不一致	高	在最终构建后重新生成SBOM

关键提醒：每次RTA平均导致约22个日历日的延误，严重影响产品上市进度。中国企业在准备FDA申请时，应将SBOM生成纳入持续集成/持续部署（CI/CD）流程，确保每次构建自动生成符合规范的SBOM。

2.4 SBOM数据标准化挑战：FDA委托MITRE白皮书（2024年10月）

2024年10月，MITRE公司受FDA委托发布了一份关于医疗器械SBOM数据质量与标准化的白皮书——《Software Bill of Materials (SBOM) Data Quality and Standardization for Medical Devices》。这份白皮书基于对实际提交给FDA的SBOM文件的系统性分析，揭示了当前SBOM实践中的严重数据一致性问题，并为行业改进提供了具体建议。

白皮书的核心发现：

问题领域	具体挑战	影响
组件命名不一致	同一软件组件在不同SBOM中的名称可能不同（如"OpenSSL"vs"openssl"vs"OpenSSL Library"）	自动化漏洞匹配失败，无法跨SBOM聚合分析
唯一标识符混乱	CPE（Common Platform Enumeration）与PURL（Package URL）两大标识体系并存，映射关系不完善	跨系统关联困难，NVD漏洞匹配准确率下降
版本格式差异	不同生态系统的版本号格式不统一（SemVer vs 日期版本 vs 供应商自定义版本）	版本比较与漏洞范围判断不准确
供应商信息缺失	许多SBOM中缺少供应商信息或使用非标准化的供应商名称	无法准确追溯组件来源
SBOM深度不足	部分SBOM仅列出顶层组件，缺少传递依赖信息	无法发现深层次的供应链风险
工具间输出差异	不同SCA工具对同一项目生成的SBOM在组件数量和元数据上存在显著差异	审评人员难以判断SBOM的完整性

MITRE白皮书的关键建议：

建议领域	具体建议
标识符标准化	优先使用PURL作为组件唯一标识符，因其对软件包生态的映射更精确
命名规范	建立组件名称的标准化映射表（canonical name mapping）
工具验证	使用多个SCA工具交叉验证SBOM的完整性
数据治理	在SBOM生成流程中加入自动化数据质量检查环节
格式合规	严格遵循SPDX或CycloneDX的schema验证，避免非标准化扩展

这份白皮书对中国企业的实际启示是：仅仅"生成"一份SBOM是不够的，还需确保SBOM中的数据质量。建议企业在SBOM生成流程中加入数据标准化环节，统一使用PURL作为组件唯一标识符，使用schema验证工具（如SPDX Tools或CycloneDX CLI的validate命令）对生成的SBOM进行合规性检查，并在提交FDA前进行SBOM数据质量审查。

三、欧盟网络韧性法案（CRA）与MDR/IVDR的SBOM要求

3.1 欧盟网络韧性法案（CRA）概述

2024年，欧盟正式通过了《网络韧性法案》（Cyber Resilience Act, CRA，法规编号EU 2024/2847），这是全球首部全面规范数字产品网络安全的立法。CRA适用于所有"具有数字元素的产品"（Products with Digital Elements），其中明确包含联网医疗器械和医疗器械软件。

CRA的核心条款结构：

条款	内容	与SBOM的关系
第13条	制造商义务	制造商必须确保产品在整个生命周期内的网络安全
附件一	基本网络安全要求	包括漏洞处理、安全更新等SBOM相关要求
附件二	技术文档要求	明确要求提供SBOM
第14条	漏洞报告义务	主动利用的漏洞需在24小时内向ENISA报告
第15条	安全更新义务	在产品支持期限内免费提供安全更新

3.2 CRA附件二中的SBOM条款

CRA附件二（Annex II）对技术文档的要求中明确将SBOM列为必备文件：

"技术文档应包含……对软件物料清单（SBOM）的描述，该清单至少应涵盖产品中包含的顶层依赖项。"

——CRA附件二第2条

CRA对SBOM的具体要求：

要求	说明
覆盖范围	至少涵盖顶层依赖项（top-level dependencies）
文档格式	应采用"通用且机器可读的格式"
更新义务	在软件版本变更后应及时更新SBOM
可追溯性	SBOM应能追溯到具体的产品版本
公开性	下游用户和市场监管机构有权获取SBOM

3.3 CRA与MDR/IVDR的关系

对于医疗器械企业，CRA与MDR（EU 2017/745）/IVDR（EU 2017/746）的关系需要厘清：

核心原则——"无双重监管"：

CRA第12条明确规定：如果产品已受到等效水平的欧盟立法（如MDR/IVDR）监管，则CRA的相关条款不再重复适用。但关键在于"等效水平"的判断：

合规领域	MDR/IVDR是否覆盖	CRA是否补充适用
上市前安全评估	是（CE认证）	否
SBOM技术文档	MDR尚无明确SBOM条款	可能补充适用
漏洞披露与响应	MDCG 2019-16（指南级别）	CRA提升为法规级别要求
上市后安全更新	PMS体系（MDR第83-86条）	CRA提供更细化的安全更新要求

实际影响：即便医疗器械主要受MDR/IVDR监管，SBOM的准备已经成为事实上的合规标配，原因包括：

MDCG（医疗器械协调组）发布的网络安全指南MDCG 2019-16已将SBOM列为推荐内容
公告机构在审核技术文档时越来越多地要求提供SBOM
CRA的SBOM条款可能在MDR未明确覆盖的领域补充适用
市场监管机构（如德国BfArM）已开始在上市后监督中要求制造商提供SBOM

如需了解欧盟医疗器械网络安全监管的完整体系，请参阅：欧盟医疗器械网络安全合规指南。

3.4 CRA实施时间线

时间节点	里程碑
2024年12月	CRA正式生效
2025年12月	漏洞报告义务开始适用（第14条）
2026年12月	合格评定机构要求生效
2027年12月	CRA全面适用，包括SBOM要求

四、NMPA SBOM要求：中国医疗器械网络安全注册审查

4.1 法规框架

中国NMPA的SBOM要求主要体现在《医疗器械网络安全注册审查指导原则》（2024年修订版）及其配套标准中。相较于FDA的立法层面强制和欧盟CRA的法规层面强制，NMPA的SBOM要求目前处于指导原则层面，但在实际审评中已具有"准强制"效力。

相关法规文件层级：

文件	层级	SBOM相关要求
《医疗器械监督管理条例》（国务院令739号）	行政法规	安全有效性总体要求
《医疗器械注册与备案管理办法》	部门规章	注册资料要求
《医疗器械网络安全注册审查指导原则》（2024年修订版）	指导原则	明确要求提供SBOM
《医疗器械软件注册审查指导原则》（2022年修订版）	指导原则	软件组成描述要求
GB/T 42062-2022（等同IEC 81001-5-1）	推荐性国标	安全活动中的软件组成管理

IEC 81001-5-1中的SBOM专项要求：

IEC 81001-5-1:2021《健康软件和健康IT系统——安全、有效性和安全性——第5-1部分：安全性——产品生命周期中的活动》是医疗器械软件安全领域的关键国际标准。它不仅是NMPA推荐性国标GB/T 42062-2022的等同采用标准，也是EU MDR框架下预期将被协调的重要标准之一。该标准第8章（安全维护过程）和第9章（安全问题管理过程）对SBOM提出了超越通用SBOM格式的特殊要求，这些要求在现有SPDX和CycloneDX标准中尚未得到完全支持：

IEC 81001-5-1要求	标准条款	说明	当前格式支持情况
组件状态跟踪	8.2 / 8.3	要求标注每个组件的维护状态——"maintained"（仍在积极维护）、"supported"（仍有安全补丁支持但不再进行功能更新）、"required"（产品运行所必需的组件）	SPDX/CycloneDX 部分支持，需通过自定义属性（Custom Properties）扩展
EOL/EOS预警	8.2	要求对即将到达生命周期终点（End-of-Life/End-of-Support）的组件进行预警和替代规划	CycloneDX v1.5+支持lifecycle字段，SPDX需自定义
安全异常管理	9.1 / 9.2	要求记录已知安全异常（Known Security Anomalies）及其缓解措施，包括无法修复的残余风险	可通过VEX文档补充，但格式未完全对齐IEC 81001-5-1的结构化要求
供应商安全通信	8.4	要求建立与组件供应商的安全信息共享机制，确保及时获取安全更新通知	SBOM格式未覆盖，需流程文档（SOP）补充
退役计划	8.5	要求对不再维护的组件制定退役计划，包括替代方案和时间表	需在SBOM之外单独管理
安全更新交付	8.3	要求具备向用户交付安全更新的能力，并基于SBOM追踪更新覆盖率	SBOM可提供基础数据，但交付机制需额外实现

IEC 81001-5-1组件状态跟踪的实操实现：

由于SPDX和CycloneDX标准格式尚未原生支持IEC 81001-5-1要求的所有状态字段，企业可采用以下补充方案：

实现方式	适用格式	示例
CycloneDX Custom Properties	CycloneDX JSON/XML	在component对象中添加 `"properties": [{"name": "iec81001-5-1:status", "value": "maintained"}]`
SPDX Annotation	SPDX 2.3 JSON	使用Annotation字段记录组件状态信息
补充说明文档	任意格式	提供独立的Excel/PDF文档，列出每个组件的IEC 81001-5-1状态评估

IEC 81001-5-1的EU MDR协调标准前景：

IEC 81001-5-1目前正处于欧盟MDR协调标准化（harmonisation）的推进过程中。一旦正式成为协调标准（harmonised standard），其SBOM相关要求将获得以下法律效力：

符合性推定：满足IEC 81001-5-1要求的制造商，可被推定满足MDR附件I中对应的基本安全与性能要求
公告机构审核依据：公告机构将以此标准作为网络安全审核的基准
SBOM要求升级：IEC 81001-5-1中的SBOM条款将从"最佳实践"升级为实质性合规要求

重要提示：当前主流SBOM格式（SPDX和CycloneDX）尚未完全满足IEC 81001-5-1的所有要求，特别是在组件状态跟踪方面。企业在生成SBOM时，建议通过自定义属性（Custom Properties）补充IEC 81001-5-1所要求的额外信息，或以附件形式提供补充说明。鉴于IEC 81001-5-1成为EU MDR协调标准的趋势已非常明确，建议企业现在就开始按照IEC 81001-5-1的要求准备SBOM，而非等到协调标准正式公布后再仓促应对。

如需深入了解NMPA网络安全要求的完整体系，请参阅：NMPA医疗器械网络安全合规全攻略。

4.2 NMPA对SBOM的具体要求

2024年修订版《医疗器械网络安全注册审查指导原则》在多处涉及SBOM：

SBOM必须包含的信息：

字段	要求	说明
组件名称	必填	包括自研组件与第三方组件
版本号	必填	需精确到最小版本号
供应商/来源	必填	开源项目名称或商业供应商
许可证类型	必填	特别关注开源许可证合规
已知漏洞	必填	CVE编号及风险评估
功能描述	建议	组件在产品中的功能角色
依赖关系	建议	上下游依赖链

NMPA审评中的SBOM审查重点：

审查项	审评关注点
完整性	SBOM是否覆盖了所有可识别的软件组件
漏洞状态	是否对已知漏洞进行了风险评估与缓解
开源合规	开源组件的许可证是否合规，是否存在许可证冲突
支持状态	是否包含已停止维护（EOL）的组件
一致性	SBOM内容与实际产品软件版本是否一致
更新机制	是否描述了SBOM的持续更新与维护机制

4.3 22项网络安全能力中的SBOM定位

NMPA指导原则要求医疗器械制造商具备22项网络安全能力。其中，与SBOM直接相关的能力包括：

能力编号	能力名称	与SBOM的关系
能力1	自动注销	间接：需了解会话管理组件
能力2	审计日志	间接：需了解日志组件版本
能力7	软件维护	直接相关：基于SBOM进行补丁管理
能力11	加密传输	间接：需了解TLS/SSL库版本
能力13	恶意软件防护	间接：基于SBOM验证组件完整性
能力17	安全指导	间接：SBOM信息用于编写安全使用指南
能力19	软件物料清单	核心要求：提供完整SBOM
能力22	上市后管理	直接相关：基于SBOM的持续漏洞监控

4.4 中美欧SBOM要求对比

维度	FDA（美国）	CRA（欧盟）	NMPA（中国）
法律层级	立法（FD&C Act 524B）	法规（EU Regulation）	指导原则（准强制）
生效状态	已强制执行	2027年12月全面适用	审评中事实执行
覆盖深度	传递依赖（合理深度）	至少顶层依赖	鼓励完整覆盖
格式要求	SPDX/CycloneDX（机器可读）	机器可读格式	未强制指定格式
CVE评估	必须包含	必须包含	必须包含
更新频率	每次发布	版本变更后更新	变更后更新
缺失后果	RTA（拒绝受理）	不得上市/罚款	补正/发补

五、IMDRF国际协调：SBOM全球统一框架

5.1 IMDRF N73——医疗器械SBOM最重要的国际协调文件

2023年4月，国际医疗器械监管机构论坛（IMDRF）网络安全工作组正式发布了IMDRF/CYBER WG/N73FINAL:2023《医疗器械网络安全软件物料清单的原则与实践》（Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity）。这是目前全球范围内关于医疗器械SBOM最具权威性和综合性的国际协调文件，为各国监管机构的SBOM要求提供了统一的参考框架。

N73文件基本信息：

属性	详情
文件编号	IMDRF/CYBER WG/N73FINAL:2023
发布日期	2023年4月
发布机构	IMDRF网络安全工作组（Cybersecurity Working Group）
文件类型	指导性文件（非强制性法规，但各成员国监管机构在制定本国要求时高度参考）
适用范围	制造商、医疗机构（HDOs）、监管机构、安全研究人员
核心主题	SBOM的生成、消费、管理的原则与实践指南

N73的战略意义：

IMDRF成员包括FDA（美国）、欧盟委员会、NMPA（中国）、MHLW/PMDA（日本）、TGA（澳大利亚）、Health Canada（加拿大）、ANVISA（巴西）、MFDS（韩国）等全球主要医疗器械监管机构。N73文件的发布意味着各主要市场的SBOM要求将趋向统一，企业只需建立一套SBOM管理体系，即可满足多市场的合规需求。

N73与其他SBOM要求的关系：

文件/法规	与N73的关系
FDA 524B / 网络安全最终指南	FDA的SBOM要求与N73高度对齐，N73可视为FDA要求的国际化版本
EU CRA附件二	CRA的SBOM条款在覆盖范围上与N73一致，N73提供了更详细的实操指导
NMPA网络安全指导原则	NMPA作为IMDRF成员，其SBOM要求正在向N73靠拢
NTIA Minimum Elements	N73明确引用NTIA最低要求作为SBOM数据字段的基准
IEC 81001-5-1	N73与IEC 81001-5-1在组件管理和安全维护方面形成互补

5.2 N73核心内容解读

N73文件围绕四类利益相关者（制造商、医疗机构、监管机构、安全研究人员）分别提出了SBOM最佳实践：

制造商的SBOM责任：

责任领域	N73要求	实操建议
SBOM生成	在软件开发生命周期中自动化生成SBOM	集成到CI/CD流水线
SBOM内容	至少覆盖NTIA Minimum Elements全部字段	使用SPDX或CycloneDX标准格式
SBOM维护	软件每次更新时同步更新SBOM	自动化触发，避免手工滞后
SBOM共享	在合理条件下向医疗机构和监管机构提供SBOM	建立分级共享机制（完整版/摘要版）
漏洞响应	基于SBOM的持续漏洞监控与及时通报	结合VEX声明，说明漏洞实际影响

医疗机构（Healthcare Delivery Organizations, HDOs）的SBOM使用指南：

N73明确了医疗机构作为SBOM消费者的角色，建议HDOs：

在医疗器械采购中将SBOM纳入采购条款
利用SBOM评估设备引入医院网络的安全风险
当新漏洞发布时，基于SBOM快速评估自身设备的影响范围
建立SBOM接收、存储和使用的内部流程

监管机构的SBOM审查指导：

N73建议监管机构在SBOM审查中关注以下方面：

审查维度	具体关注点
完整性	SBOM是否覆盖所有已知组件，包括传递依赖
准确性	SBOM中的信息是否与实际软件构建一致
时效性	SBOM是否反映最新的软件版本
可用性	SBOM是否采用机器可读的标准格式
漏洞管理	制造商是否基于SBOM建立了持续的漏洞监控机制

5.3 N73中的SBOM生命周期管理要求

N73不仅定义了SBOM应包含的数据内容，还对SBOM的生成（Generation）、消费（Consumption）和管理（Management）三个阶段提出了系统性指导：

SBOM生成（Generation）：

N73要求	说明
自动化优先	应在软件构建流程中自动化生成SBOM，而非手工编制
构建时生成	SBOM应在每次正式构建（build）时同步生成，确保与交付软件版本一致
多层级覆盖	至少覆盖NTIA定义的最低要素字段，鼓励提供更深层次的传递依赖信息
签名与完整性	建议对SBOM文件进行数字签名，确保传输过程中未被篡改

SBOM消费（Consumption）：

消费者角色	N73建议的消费方式
监管机构	审查SBOM完整性、准确性和时效性，评估制造商的供应链安全管理能力
医疗机构（HDOs）	在采购评估和网络安全风险评估中使用SBOM，当新CVE发布时基于SBOM评估影响范围
安全研究人员	利用SBOM快速定位受影响设备，支持协调漏洞披露（CVD）流程
供应链合作伙伴	基于SBOM评估上游组件的安全风险，建立供应链信任链

SBOM管理（Management）：

管理要求	说明
版本化管理	每个软件版本对应一份唯一的SBOM，版本号与软件发布版本绑定
持续更新	软件组件发生变更时必须重新生成SBOM
安全存储	SBOM可能包含敏感的软件架构信息，应在适当的访问控制下存储
分级共享	N73建议建立分级共享机制——完整版SBOM提供给监管机构，摘要版提供给医疗机构客户
保留期限	应至少保留至产品退市后的合理期限，以支持上市后安全监控

5.4 遗留设备（Legacy Devices）的SBOM处理

N73对遗留设备（已上市且可能无法完整重新分析的设备）提出了务实的处理方案，这对中国企业尤为重要，因为许多已上市产品在最初注册时并未考虑SBOM要求：

遗留设备场景	N73建议	实操工具
有完整源代码但未生成过SBOM	使用SCA工具回溯生成SBOM	Syft、Trivy、FOSSA
仅有二进制文件	使用二进制分析工具生成"尽力而为"的SBOM，标注分析局限性	Black Duck Binary Analysis、SCANOSS
已停产但仍在使用	提供缩减范围的SBOM（Reduced-scope SBOM），至少覆盖顶层组件和已知安全关键组件	手工编制 + SCA辅助
供应商已不存在	在SBOM中标注"已知未知"（known unknowns）区域，并提供替代的风险缓解措施	文档记录
第三方组件无法获取源码	要求供应商提供组件级SBOM，或通过二进制分析补充	采购合同约束 + 二进制分析

N73的核心理念：对于遗留设备，"不完美的SBOM也好过没有SBOM"（An imperfect SBOM is better than no SBOM）。企业不应因为无法生成完美的SBOM而完全放弃，而是应在可行范围内提供尽可能完整的信息，并透明地标注信息缺失的区域。N73特别强调，对于遗留设备的SBOM，制造商应明确标注SBOM的置信度等级（confidence level），让消费者了解数据的可靠程度。

5.5 N73对中国企业的指导意义

对于中国医疗器械企业，N73提供了以下关键指导：

统一标准：基于N73建立的SBOM管理体系，可以一次建设、多市场复用
提前准备：NMPA作为IMDRF成员，未来的SBOM要求很可能与N73对齐
供应商谈判：可引用N73作为向上游供应商索要SBOM的国际依据
共享机制：N73的分级共享建议为企业的SBOM信息安全管理提供了框架

六、SBOM格式标准深度对比：SPDX vs CycloneDX vs SWID

6.1 三大标准概述

目前国际上主流的SBOM格式标准有三个，各有侧重：

标准	维护组织	国际标准化	核心定位
SPDX	Linux基金会	ISO/IEC 5962:2021	许可证合规 + 通用SBOM
CycloneDX	OWASP	ECMA-424（2024年通过）	安全与风险管理
SWID	ISO/NIST	ISO/IEC 19770-2	软件资产管理

6.2 详细对比

对比维度	SPDX	CycloneDX	SWID
支持格式	JSON, XML, YAML, RDF, Tag-Value	JSON, XML, Protobuf	XML
许可证信息	最优：原生支持SPDX License List	支持	有限
漏洞关联	v2.3起支持	最优：原生VEX支持	不支持
VEX支持	通过外部文档关联	原生集成	不支持
依赖关系表达	支持	最优：嵌套组件树	有限
硬件BOM支持	有限	支持（HBoM）	不支持
服务/API描述	有限	支持	不支持
工具生态	丰富	最丰富	较少
学习曲线	中等	较低	较高
FDA推荐	是	是	不推荐

6.3 医疗器械企业如何选择

推荐策略：

场景	推荐格式	理由
目标市场为美国（FDA）	CycloneDX或SPDX	两者均被FDA接受，CycloneDX的VEX支持更利于漏洞管理
目标市场为欧盟（CRA）	SPDX或CycloneDX	CRA未限定格式，但SPDX是ISO标准具有天然优势
目标市场为中国（NMPA）	CycloneDX或SPDX	NMPA未限定格式，但机器可读格式更受审评欢迎
全球多市场同步注册	CycloneDX（主） + SPDX（辅）	CycloneDX在安全场景更全面，SPDX在许可证合规更权威
开源合规为核心需求	SPDX	SPDX License List是许可证标准化的行业基准
安全漏洞管理为核心需求	CycloneDX	原生VEX支持大幅简化漏洞响应流程

5.4 什么是VEX？

VEX（Vulnerability Exploitability eXchange，漏洞可利用性交换）是SBOM的重要补充文档。当SBOM中列出的某个组件存在已知CVE时，VEX用于声明该漏洞在特定产品上下文中的实际影响状态：

VEX状态	含义	示例
Not Affected	产品不受该漏洞影响	"该CVE影响的代码路径在我们的产品中未被使用"
Affected	产品受影响，需要采取措施	"该CVE影响我们的TLS通信模块"
Fixed	漏洞已在当前版本中修复	"已在v2.1.3中通过更新OpenSSL修复"
Under Investigation	正在评估影响	"漏洞影响范围正在分析中"

VEX在FDA审评中具有重要价值：它帮助审评人员理解制造商已知晓漏洞并做出了合理评估，而不是简单地忽略或遗漏了安全风险。

七、SBOM生成工具与自动化工作流

6.1 主流SBOM生成工具

工具名称	类型	支持格式	主要特点	适用场景
Syft	开源	SPDX, CycloneDX	轻量快速，支持容器镜像/文件系统扫描	CI/CD集成、嵌入式Linux
Trivy	开源	SPDX, CycloneDX	SBOM生成 + 漏洞扫描一体化	云端SaMD、容器化部署
FOSSA	商业	SPDX, CycloneDX	许可证合规 + SBOM管理平台	大型企业、多产品线管理
Black Duck	商业	SPDX, CycloneDX	企业级SCA + SBOM，漏洞数据库全面	严格合规要求的大型医械企业
Snyk	商业	CycloneDX	开发者友好，IDE集成	开发阶段的实时漏洞检测
CycloneDX CLI	开源	CycloneDX	官方命令行工具，支持多语言项目	标准化CycloneDX输出
SPDX Tools	开源	SPDX	Linux基金会官方工具，验证SPDX合规性	SPDX格式验证与转换
Microsoft SBOM Tool	开源	SPDX	微软出品，集成Azure DevOps	Windows平台、.NET项目
SCANOSS	开源	SPDX, CycloneDX	代码片段级别识别	检测代码复用与抄袭

6.2 SCA（软件组成分析）与SBOM的关系

SCA（Software Composition Analysis，软件组成分析）工具是SBOM生成的核心技术基础。SCA通过分析项目的依赖声明文件（如package.json、pom.xml、requirements.txt）、二进制文件和源代码，自动识别项目中包含的所有组件及其版本。

SCA工具的核心能力：

能力	说明	与SBOM的关系
组件识别	自动扫描识别所有依赖项	SBOM数据的主要来源
漏洞匹配	将组件版本与CVE数据库比对	为SBOM中的漏洞评估提供数据
许可证检测	识别每个组件的许可证类型	SBOM中的许可证信息来源
传递依赖解析	递归解析依赖树到最深层	确保SBOM的覆盖深度
策略执行	自动阻断不合规的组件引入	在SBOM生成前实施质量关卡

6.3 推荐的SBOM自动化工作流

对于需要同时满足FDA、CRA和NMPA要求的中国医疗器械企业，推荐以下自动化工作流：

阶段一：开发阶段（Shift-Left）

步骤	工具示例	产出
1. 依赖声明管理	npm/Maven/pip + lock文件	固定的依赖版本声明
2. 开发者IDE扫描	Snyk IDE插件	实时漏洞告警
3. 提交前检查（Pre-commit）	CycloneDX CLI	本地SBOM草稿

阶段二：CI/CD集成

步骤	工具示例	产出
4. 自动SBOM生成	Syft / Trivy	机器可读SBOM文件（JSON/XML）
5. 漏洞扫描	Trivy / Grype	CVE清单 + 风险评级
6. 许可证合规检查	FOSSA / ScanCode	许可证合规报告
7. 策略门禁（Policy Gate）	OPA / 自定义脚本	阻断含高危CVE的构建

阶段三：发布与提交

步骤	工具示例	产出
8. SBOM版本化存储	Git / Artifactory	与产品版本绑定的SBOM档案
9. VEX文档生成	CycloneDX VEX	漏洞可利用性声明
10. 合规报告生成	自定义模板	FDA/NMPA格式的合规报告
11. 签名与时间戳	Sigstore / OpenPGP	SBOM的完整性与不可否认性

6.4 嵌入式医疗器械的特殊考量

嵌入式医疗器械（如监护仪、输液泵、影像设备）的SBOM生成面临特殊挑战：

挑战	说明	应对策略
二进制分析	嵌入式固件通常以二进制形式交付	使用二进制SCA工具（如Black Duck Binary Analysis）
RTOS组件	实时操作系统组件识别困难	维护内部RTOS组件清单，手动补充SBOM
硬件驱动	硬件驱动程序的来源追溯复杂	与硬件供应商合作获取驱动SBOM
遗留系统	老旧设备可能缺乏源代码	逆向工程 + 二进制分析补全
Yocto/Buildroot	Linux嵌入式构建系统	利用Yocto原生SPDX输出能力

八、中国医疗器械企业SBOM合规实操指南

7.1 合规路线图

对于计划进入全球市场的中国医疗器械企业，建议按以下路线图推进SBOM合规：

第一阶段：基础建设（1-3个月）

任务	具体行动	产出
1. 组织准备	指定SBOM负责人（通常为软件质量经理或网络安全工程师）	SBOM责任矩阵
2. 工具选型	评估并选定SBOM生成工具（建议先从开源工具Syft/Trivy入手）	工具选型报告
3. 格式确定	根据目标市场选择SBOM格式（推荐CycloneDX）	SBOM格式规范文档
4. 清单梳理	对现有产品进行初步的软件组件盘点	初版组件清单

第二阶段：流程集成（3-6个月）

任务	具体行动	产出
5. CI/CD集成	将SBOM生成工具集成到构建流水线	自动化SBOM生成流水线
6. 漏洞监控	建立CVE监控与告警机制	漏洞监控仪表盘
7. 策略制定	制定组件引入策略（许可证白名单、CVE严重度阈值）	软件组件管理策略
8. 流程文档	编写SBOM相关的SOP和作业指导书	QMS文件（SOP）

第三阶段：合规提交（6-9个月）

任务	具体行动	产出
9. 全量SBOM生成	为所有在售/在研产品生成完整SBOM	各产品SBOM档案
10. VEX编写	对已知CVE进行逐一评估，生成VEX声明	VEX文档
11. 审评预沟通	与FDA Pre-Sub或NMPA审评中心进行SBOM相关咨询	预沟通反馈
12. 注册提交	将SBOM纳入技术文档提交	合规的注册申报资料

7.2 组织架构建议

SBOM合规涉及多个部门的协作，建议建立以下组织架构：

角色	职责	建议归属部门
SBOM总负责人	整体合规策略、监管沟通	法规事务部（RA）
SBOM技术负责人	工具选型、流程设计、自动化实施	软件研发部
漏洞响应负责人	CVE监控、风险评估、补丁管理	网络安全/信息安全部门
许可证合规负责人	开源许可证审查、合规政策制定	法务部/知识产权部
QMS文档负责人	SOP编写、培训、内审	质量管理部
供应商管理负责人	第三方组件供应商的SBOM索取与验证	供应链管理部

7.3 常见误区与纠正

误区	正确做法
"SBOM只是一个Excel清单"	SBOM必须是机器可读的结构化文件（SPDX/CycloneDX格式）
"只列出顶层依赖就够了"	FDA要求覆盖传递依赖到合理深度，建议至少覆盖3层以上
"SBOM做一次就行"	SBOM必须随产品版本同步更新，建议集成到CI/CD流程中
"只需要列出组件名和版本"	还需要包含供应商、许可证、已知CVE、依赖关系等信息
"开源组件不需要管"	开源组件是SBOM审查的重点，需关注许可证合规和漏洞状态
"SBOM是软件团队的事"	SBOM合规需要RA、QA、研发、法务、安全等多部门协作
"我们产品简单，不需要SBOM"	只要产品含软件且具备网络连接能力，就需要SBOM
"用Excel或PDF提交给FDA"	FDA明确要求机器可读格式，Excel/PDF会导致RTA

九、SBOM生命周期管理与漏洞监控

8.1 SBOM生命周期管理框架

SBOM不是一次性文件，而是需要贯穿产品全生命周期持续管理的"活文档"。以下是推荐的SBOM生命周期管理框架：

阶段	SBOM活动	频率	工具支持
需求分析	制定SBOM策略、选择格式和工具	项目启动时	—
设计开发	对新引入组件进行安全与许可证评估	每次引入新组件	Snyk、FOSSA
代码构建	自动化SBOM生成、漏洞扫描	每次构建	Syft、Trivy
验证测试	SBOM完整性验证、与实际构建对比	每个里程碑	SPDX Tools
注册提交	冻结SBOM版本、生成VEX、合规审查	注册送审前	CycloneDX VEX
上市后监控	持续CVE监控、影响评估	持续（建议每日）	OSV、Grype
变更管理	组件更新后重新生成SBOM	每次软件变更	CI/CD自动触发
退市管理	评估遗留组件风险、通知用户	退市决策时	—

8.2 持续漏洞监控体系

SBOM的核心价值之一是支撑持续的漏洞监控。以下是推荐的监控体系：

漏洞数据源：

数据源	说明	更新频率
NVD（National Vulnerability Database）	美国NIST维护的CVE数据库	每日
CISA KEV（Known Exploited Vulnerabilities）	已被实际利用的漏洞目录	不定期
OSV（Open Source Vulnerability）	Google维护的开源漏洞数据库	每日
GitHub Advisory Database	GitHub安全公告数据库	实时
CNVD（中国国家信息安全漏洞共享平台）	中国漏洞数据库	每日
供应商安全公告	各组件供应商发布的安全通知	不定期

漏洞响应流程：

步骤	活动	时间要求
1. 漏洞发现	通过监控系统匹配SBOM中的组件	自动化，实时
2. 影响评估	确定漏洞是否影响本产品（参考VEX状态）	24-48小时内
3. 风险分级	使用CVSS评分和产品上下文评估实际风险	48小时内
4. 修复决策	决定补丁策略（更新、缓解、接受）	72小时内
5. 补丁开发	开发、测试安全补丁	根据风险等级（高危：7天内）
6. 验证发布	回归测试、SBOM更新、补丁发布	根据QMS流程
7. 监管通报	必要时向FDA/NMPA/主管当局报告	根据法规要求
8. 用户通知	向医疗机构和用户通知更新	补丁发布后立即

8.3 SBOM存储与版本管理

推荐的SBOM存档策略：

策略	说明
版本绑定	每个产品软件版本对应一份SBOM，版本号一一对应
不可变存储	SBOM一旦与某版本绑定，不应被修改（仅可追加VEX）
签名验证	对SBOM文件进行数字签名，确保完整性
保留期限	至少保留至产品退市后10年（满足MDR/FDA记录保留要求）
访问控制	限制SBOM的内部访问权限，同时确保监管机构可获取
多格式存储	同时保留CycloneDX和SPDX格式以应对不同监管要求

如需了解医疗器械软件开发生命周期管理的完整框架，请参阅：IEC 62304医疗器械软件生命周期合规指南。

十、常见问题（FAQ）

Q1：我们的产品是纯硬件设备，没有软件，需要SBOM吗？

如果产品确实不包含任何软件、固件或可编程逻辑，则不需要SBOM。但需要注意：现代医疗器械中，即使看似"纯硬件"的产品（如电子血压计、血糖仪）也通常包含嵌入式固件，需要仔细评估。

Q2：SBOM中是否需要包含自研代码的具体模块？

是的。FDA和NMPA都要求SBOM覆盖自研组件。但与开源/第三方组件不同，自研组件不需要提供外部许可证信息，主要需要提供模块名称、版本号和功能描述。

Q3：如果SBOM中的某个组件存在已知CVE但我们评估认为不影响产品安全，如何处理？

这正是VEX的用武之地。您应当生成一份VEX文档，将该CVE的状态标记为"Not Affected"，并提供技术理由（如"受影响的代码路径在本产品中未被调用"）。FDA和NMPA审评人员都会审查您的风险评估是否合理。

Q4：开源组件的许可证合规和SBOM有什么关系？

SBOM是许可证合规管理的基础设施。通过SBOM，您可以快速识别所有开源组件的许可证类型。需要特别关注的许可证风险包括：

许可证类型	风险等级	注意事项
MIT / BSD / Apache 2.0	低	宽松许可，通常可自由使用
LGPL	中	动态链接通常可以，静态链接有披露要求
GPL v2/v3	高	具有"传染性"，需仔细评估
AGPL	极高	网络交互也触发许可证义务
无许可证	极高	法律上默认保留所有权利，不可使用

Q5：SBOM需要提交给公告机构（Notified Body）吗？

在欧盟MDR/IVDR框架下，公告机构有权审查技术文档中的所有内容，SBOM作为网络安全文档的一部分应包含在技术文档中。越来越多的公告机构在审核时主动要求查看SBOM，特别是对于IIb和III类医疗器械以及Class C/D类IVD。

Q6：SBOM是否需要对外公开？

各监管体系的要求不同：

监管体系	公开要求
FDA	不要求向公众公开，但FDA审评人员可查看
CRA	下游用户和市场监管机构有权获取
NMPA	不要求公开，作为注册资料内部审查

建议企业建立分级披露策略：监管机构获取完整SBOM，医疗机构客户在NDA下获取必要组件信息。

Q7：旧产品（已上市产品）需要补做SBOM吗？

从监管合规角度：

FDA：如果产品需要提交变更申请（如510(k)补充申请），新提交必须包含SBOM
CRA：2027年12月全面适用后，仍在市场上销售的产品需要合规
NMPA：产品延续注册或变更注册时，审评中心可能要求补充SBOM

从安全管理角度：强烈建议为所有在售产品补做SBOM，以支撑漏洞监控和补丁管理。

Q8：如何处理供应商不愿提供其组件SBOM的情况？

这是当前行业面临的普遍挑战。建议采取以下措施：

合同约束：在采购合同中增加SBOM条款，要求供应商提供组件SBOM
二进制分析：使用二进制SCA工具（如Black Duck Binary Analysis）对供应商组件进行扫描
替代评估：评估是否有可提供SBOM的替代供应商
风险记录：如果实在无法获取，在技术文档中记录"已知未知"区域，并说明缓解措施
行业推动：参与IMDRF等国际组织的供应链安全倡议

Q9：SBOM合规的预算大概需要多少？

企业规模	方案	估算年度投入
初创/小型（1-3个产品）	开源工具（Syft + Trivy + Grype）	人力成本为主（1名兼职工程师）
中型（3-10个产品）	开源工具 + 商业SCA（如Snyk Team）	约10-30万元（含工具许可与人力）
大型（10个以上产品）	企业级平台（Black Duck / FOSSA）	约50-150万元（含平台、集成、培训）

Q10：SBOM与IEC 62304的关系是什么？

IEC 62304要求在软件开发过程中进行"软件组成管理"，包括识别和记录所有软件组件。SBOM可以被视为IEC 62304中软件配置管理（Configuration Management）要求的一个具体落地形式。已经实施IEC 62304的企业，在SBOM合规上通常具有良好的基础，只需将现有的配置管理数据转换为标准化的SBOM格式（SPDX/CycloneDX）即可。如需深入了解IEC 62304的合规要求，请参阅：IEC 62304医疗器械软件生命周期合规指南。

Q11：我们已经按IEC 62304维护了SOUP清单，还需要单独做SBOM吗？

是的，需要。SOUP清单和SBOM虽然有数据重叠，但服务于不同目的、面向不同受众：

SOUP清单是IEC 62304框架下的内部风险管理文档，聚焦于外部引入组件的功能安全风险评估，通常以Word/Excel形式维护，仅在内部质量体系中使用
SBOM是网络安全透明度工具，面向监管机构和外部利益相关者共享，必须采用SPDX/CycloneDX等机器可读格式，且覆盖范围更广（包括自研代码和传递依赖）

好消息是，已有SOUP清单的企业不需要从零开始。建议以自动化SCA工具生成的SBOM为基础数据源，同时从中导出满足IEC 62304要求的SOUP清单，确保"一份数据、两种用途"，避免手工维护两套不一致的文档。详见本文第1.4节的详细对比和过渡路径。

Q12：IEC 81001-5-1对SBOM有什么额外要求？标准SBOM格式够用吗？

IEC 81001-5-1对SBOM提出了超越通用SPDX/CycloneDX格式的额外要求，最突出的是组件状态跟踪——要求标注每个组件是否"maintained"（仍在维护）、"supported"（有安全支持）、"required"（产品必需）。目前SPDX和CycloneDX标准字段尚未完全覆盖这些要求。

建议企业通过CycloneDX的Custom Properties或SPDX的Annotation字段来补充IEC 81001-5-1所要求的状态信息。由于该标准预期将成为EU MDR的协调标准，现在就按其要求准备SBOM是明智的前瞻性投资。详见本文第4.1节中IEC 81001-5-1的详细解读。

十一、总结与行动建议

SBOM已从"行业最佳实践"升级为全球医疗器械市场的强制合规要求。以下是中国医疗器械企业应立即采取的行动：

短期行动（0-3个月）

意识与培训：组织研发、RA、QA团队学习SBOM基础知识与监管要求
现状评估：盘点现有产品的软件组件管理现状，识别差距
工具试用：安装并试用Syft、Trivy等开源工具，对一款产品进行SBOM生成试点
格式选定：确定企业主用的SBOM格式（推荐CycloneDX）

中期行动（3-6个月）

流程建设：制定SBOM相关SOP，集成到现有QMS体系
CI/CD集成：将SBOM自动生成工具集成到软件构建流水线
漏洞监控：建立基于SBOM的持续漏洞监控机制
供应商沟通：向关键第三方组件供应商提出SBOM交付要求

长期行动（6-12个月）

全产品覆盖：为所有在研和在售产品建立完整的SBOM档案
VEX能力：建立VEX编写和管理能力
合规提交：将SBOM纳入FDA、NMPA和EU CRA的注册申报资料
持续改进：根据审评反馈和行业发展，持续优化SBOM管理体系

在全球医疗器械监管日益趋同的大趋势下，SBOM合规不仅是市场准入的刚性需求，更是企业软件供应链安全管理能力的直接体现。中国企业应将SBOM视为提升全球竞争力的战略性投资，而非被动应对监管要求的成本负担。

本文由医药出海通专业顾问团队基于FDA、欧盟CRA、NMPA最新法规及行业实践编写。如需针对您的具体产品制定SBOM合规策略，欢迎联系我们获取定制化咨询服务。