Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity
文件编号: IMDRF/CYBER WG/N73
INFO
This content has been machine-translated from the English original.
全文
医疗器械网络安全中的软件物料清单原则和实践
Document Number: IMDRF/CYBER WG/N73
最终文档
IMDRF/CYBER WG/N73FINAL:2023 医疗器械网络安全中的软件物料清单原则和实践 编写组 医疗器械网络安全工作组
前言
© 2023年国际医疗器械监管论坛 版权所有。
本作品受版权保护。在遵守本条款和条件的前提下，您可以下载、显示、打印、翻译、修改和复制本作品的全部或部分内容，用于您个人的使用、研究、教育目的，或如果贵组织是组织，则用于贵组织的内部使用，但前提是您或贵组织不得将复制用于任何商业目的，并且保留所有版权声明。如果您使用本作品的任何部分，必须包含以下声明（删除不适用的内容）：
“[翻译或改编]自[插入出版物名称]，[出版年份]，国际医疗器械监管论坛，经国际医疗器械监管论坛授权使用。国际医疗器械监管论坛不对本[改编/翻译]的内容或准确性负责。”
除上述内容外，所有权利均保留，未经国际医疗器械监管论坛（IMDRF）事先书面许可，不得以任何方式（包括电子方式）复制或使用本材料的全部或任何部分。有关复制和权利的请求和咨询应发送给 IMDRF 秘书处。
将本文件（部分或全部）纳入其他文档，或将其翻译成其他语言，并不代表IMDRF的认可。
安德烈·里斯，IMDRF主席
内容
1. 简介 4
2. 范围 6
3. 定义 7
4. SBOM 框架概述 10
5. 制造商考虑因素概述 11
5.1. 收集 SBOM 内容 12
5.2. 生成 SBOM 12
5.3. 分发 SBOM 13
5.4. 维护 SBOM 内容 15
5.5. 挑战 15
6. 医疗服务提供商考虑因素概述 17
6.1. SBOM 导入和管理 17
7. SBOM 应用案例 20
7.1. 风险管理 20
7.2. 漏洞管理 21
7.3. 事件管理 22
8. 参考文献 23
8.1. IMDRF 文档 23
8.2. 标准 23
8.3. 监管指导和草案指导 24
8.4. 其他资源和参考 25
9. 附录 27
9.1. SBOM 组件类型和工具 27
简介
医疗设备的数字化连接使得患者护理更加高效、数据驱动和有效。利用和依赖第三方软件组件使得开发此类医疗设备更加经济、可靠，并加快了创新速度。虽然利用第三方软件组件有很多好处，但它们也可能引入网络可连接医疗设备中的网络安全风险，从而可能影响患者安全以及网络可连接医疗设备的保密性、完整性和可用性。
网络安全漏洞的独特之处在于，由于使用了常见的软件组件，它们可能影响各种看似安全且相互独立的设备，这些设备来自不同的制造商。这个问题还因这些常见组件在设备中的低可追溯性而加剧。为了解决这一全球性问题，美国国家电信和信息管理局（NTIA）于 2018 年召集了来自各个领域的利益相关者，共同探讨软件透明度。其中一个产出是软件材料清单（SBOM）的概念，NTIA将其定义为“一个或多个已识别组件、它们之间的关系以及其他相关信息的清单”。这一倡议已在国际范围内促进了 SBOM 的开发和采用。
SBOM 是一种资源，可以用于在产品全生命周期（TPLC）的各个阶段（包括上市前和上市后）中改进网络安全风险管理流程。例如，在上市前阶段，医疗器械制造商（MDMs）可以使用 SBOM 资源，在设备开发过程中跟踪已知的软件漏洞，并防止发布包含已知网络安全风险的设备。在上市后阶段，MDMs 可以将 SBOM 用作补充，以增强其漏洞监控流程，从而识别在市场上发布的高风险设备。
SBOM 可以作为主要或次要资源，支持在 TPLC 的各个阶段改进网络安全风险管理流程。这些优势可能包括但不限于：
更快、更全面的识别设备中的软件组件，
通过更明智的决策，实现更安全的软件开发，以及
促进供应商和利益相关者之间的软件透明度。
为了最大限度地利用 SBOM 的价值，它应与诸如《医疗器械网络安全（IMDRF/CYBER WG/N60FINAL:2020）中的原则和实践》中所描述的其他网络安全风险管理工具和程序一起使用，在此后也称为“IMDRF N60 指导”。IMDRF N60 将 SBOM 作为由医疗器械制造商（MDM）准备并向设备用户提供的客户安全文档的一部分。医疗器械的 SBOM 既能为 MDM 带来益处，也能为医疗服务提供者在整个 TPLC 过程中带来益处。例如，SBOM 是一种有效的工具，用于跟踪和为软件组件的生命周期结束（EOL）做好准备。如果 MDM 了解软件组件及其各自的生命周期结束日期，则 MDM 可以更好地为自己和客户做好准备，从而应对相关的风险，从而提高 MDM 的质量控制能力。设备用户可以从增加的透明度和网络安全信息披露中受益，这使他们能够根据其自身的风险状况和网络安全能力来实施网络安全活动。例如，在购买和安装之前提供的 SBOM 允许医疗服务提供者了解哪些设备可以部署以满足其风险状况，或者可能包含过时的软件，从而在购买之前，可以解决潜在的网络安全问题。制造商应在其产品中提供软件清单（SBOM）。SBOM 必须满足所有医疗专业人员（HCP）的多样化需求、资源和能力。随着 SBOM 的采用不断增长，工具、服务和网络安全成熟度的进步将使 HCP 能够充分利用 SBOM。此外，在提供 SBOM 时，客户（可以是 HCP 或患者）可以更好地评估设备的网络安全风险。
向监管机构提交的预上市 SBOM 是一种表明 MDM 具有成熟网络安全计划的指标。 SBOM 还可以使监管机构对产品进行更全面的风险评估。 在上市后，了解哪些已上市设备可以访问 SBOM，可以帮助 MDM、医疗保健提供者 (HCP) 和监管机构，利用 MDM 的信息来评估和应对威胁、漏洞和利用的影响。
随着 SBOM 在不同行业内的采用不断增长，其对组织的价值将不断提高。 利益相关者在 SBOM 的生成、管理、分发、导入和利用等方面扮演不同的角色。
本指南提供了一个关于 SBOM 的高层次描述以及生成和使用 SBOM 的最佳实践。 本文档旨在为医疗器械利益相关者（包括 MDM、医疗保健提供者 (HCP) 和监管机构）提供有关 SBOM 和软件透明度的实施的更多详细信息。 在本指南中，医疗保健提供者包括医疗服务机构 (HDO)。
有关 SBOM 益处的更多信息，请参阅 NTIA 的 FAQ 文档以及他们的“供应链中 SBOM 的角色和益处”文档。
范围
本文件从医疗设备的角度，考虑了网络安全，这些设备可能包含软件，包括固件和可编程逻辑控制器（例如：起搏器、输液泵），或者仅存在于软件中（例如：软件为医疗设备（SaMD））。本文件强调了MDM和医疗保健专业人员的角色和责任，并就实施SBOM和在医疗设备（包括体外诊断（IVD）医疗设备）中使用软件的透明度方面提供了建议。虽然主要针对MDM和医疗保健专业人员，但我们认为，包括但不限于医疗设备用户、监管机构和软件组件供应商，也可能发现本文件中讨论的概念有益。
保护网络医疗环境是医疗保健专业人员和MDM的共同责任。SBOM是一种常用的工具，可以帮助降低患者受到伤害的风险。本文件旨在：
为医疗设备制造商提供关于SBOM生成、管理和分发的建议。
为医疗保健提供者提供关于SBOM的获取和管理建议。
从医疗设备制造商和医疗保健提供者的角度，展示SBOM在风险管理、漏洞管理和事件响应中的应用案例。
SBOM不能替代全面的安全风险评估。为了进行设备级别的安全风险评估，需要了解设备的预期用途、架构和整个设备的设计。
由于大多数监管机构对医疗器械的安全性和性能拥有管辖权，因此本指南的范围仅限于考虑与受监管的医疗器械相关的患者潜在危害。不同类型的医疗器械和监管辖区的差异可能导致需要考虑不同或额外的因素的情况。例如，可能影响性能、负面影响临床操作或导致诊断或治疗错误的威胁，均属于本文件的范围。其他类型的危害，例如与数据隐私泄露相关的危害，不在本文件的范围内；然而，我们承认这些问题非常重要，并且 SBOM 可能是有用的缓解工具。
本文件不涉及与 SBOM 相关的、特定于云服务的独特问题和建议，这些服务是在远程计算环境中提供的（即，云服务是基于互联网的按需访问计算（例如，网络、服务器、存储、应用程序）服务）。作为受监管医疗器械系统的组成部分，云服务也可能对安全性产生影响。生产受监管医疗器械的制造商应了解，云服务和云软件也必须在风险评估中进行审查。由于云服务的复杂性，尤其是在制造商利用第三方云而不是制造商控制的私有云的情况下，这种第一份 IMDRF 关于 SBOM 的指导尚未明确将云技术包含在 SBOM 中。然而，随着技术的演进和从监管角度对云的理解不断深入，在 SBOM 的背景下，解决云技术的潜在风险将变得至关重要。预计，这些以及其他风险将在未来的工作中进行考虑。
本文件是与先前的 IMDRF N60 指导的补充，相关医疗器械的范围以及对潜在患者危害的关注保持不变。本文件继续认识到，网络安全是各利益相关者共同的责任。
虽然 SBOM 可以解决各种软件透明度问题，包括许可和知识产权，但本文件侧重于与 SBOM 相关的网络安全问题。
定义
对于本文档，以下术语和定义适用：IMDRF/GRRP WG/N47 FINAL:2018。
应用程序编程接口 (API): 标准软件中断、调用、函数和数据格式的集合，可供应用程序程序访问网络服务、设备或操作系统 (ISO 10303-1:2021)
资产: 具有个人、组织或政府价值的物理或数字实体 (ISO 81001-1:2021)
资产管理: 组织协调活动，以实现资产价值 (ISO/IEC 9770-5:2015)
变更管理: 记录、协调、批准和监控所有变更的过程 (ISO 81001-1:2021)
配置: 信息处理系统的硬件和软件的组织和互连方式 (ISO/IEC 2382:2015)
网络安全: 信息和系统免受未经授权的活动（例如访问、使用、披露、中断、修改或破坏）的状况，从而在整个生命周期内，相关风险（包括保密性、完整性和可用性）保持在可接受的水平。 (ISO 81001-1:2021)
网络安全事件: 确定对组织造成影响的网络安全事件，从而需要响应和恢复。 (美国国家标准与技术研究院 (2018) 改进关键基础设施网络安全的框架，版本 1.1.)
注意: 网络安全事件是可能影响组织运营（包括但不限于任务、能力或声誉）的网络安全变更。
- 组件: 指的是构成系统的一部分，该部分（a）既可以是物理上的，也可以是逻辑上的，并且（b）具有明确的功能和接口，同时（c）被视为与其他系统部分独立存在（例如，通过政策或规范）。（ISO 81001-1:2021）
注意：在医疗设备领域，组件包括任何旨在作为成品、包装和标记设备的原材料、物质、部件、软件、固件、标签或组装。
哈希, 哈希值: 通过哈希函数计算得出，是一种用于从任意长度数据的哈希值中生成固定长度随机值的计算方法。(ISO 17090-4:2020)
旧医疗器械（同义词：旧设备）： 无法合理地保护免受当前网络安全威胁的医疗器械（IMDRF/CYBER WG/N60FINAL:2020）
产品/系统生命周期： 从最初构思到最终报废和处置，产品或系统的所有阶段。 (ISO 81001-1:2021)
产品: 组织可以生产的成果，无需该组织与客户之间发生任何交易。 (ISO 81001-1:2021)
发布和更新： 对医疗器械软件所做的纠正、预防、适应性或改进性修改。
注意 1：根据 ISO/IEC 中描述的软件维护活动得出的。
14764:2006
注意 2：更新可能包括补丁和配置更改。
注意 3：适应性改进和完善性改进是软件的增强。这些
修改是指不属于医疗器械的设计规格。
存储库: 有组织且持久的数据存储，允许数据检索。(ISO/IEC/IEEE 26511:2018)
风险管理: 系统地应用管理政策、程序和实践，以进行风险分析、评估、控制和监测。 (ISO/IEC 指南 63:2019)
软件材料清单 (SBOM): 列出一种或多种已识别的组件、它们之间的关系以及其他相关信息。
注意：对于没有依赖关系的单个组件，SBOM 只是该组件的清单。“软件”可以被解释为“软件系统”，因此硬件（真实的硬件，而不是固件）和非常低级别的软件（如中央处理器 (CPU) 微码）也可以包含在内。 (NTIA Framing 软件组件透明度：建立通用的软件材料清单 (SBOM) 2021-10-21)
- 软件组件: 用于指代软件系统或元素（如模块、单元、数据或文档）的通用术语。 (IEEE 1061)
注意：一个软件组件可能包含多个单元，或包含多个低级别的软件组件。
- 软件组合分析: 使用一种或多种工具扫描代码库，以识别哪些代码（例如，闭源软件、免费开源软件、库和软件包）包含在其中。
注意：这些工具还可以检查与包含的代码相关的已报告漏洞。(https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8397.pdf)
软件透明度: 审查软件的所有框架、层次结构和组件的软件结构图。
系统: 相互作用的元素或资产的组合，以实现一个或多个功能 (ISO/IEC/IEEE 12207:2017)
第三方软件：由被认可为独立于相关方的个人或机构提供的软件。 (改编自 ISO/IEC 指南 2)
注意：通常，相关方是供应商（“第一方”）和购买方（“第二方”）的利益相关者。
用例：指定一系列操作（包括变体），一个系统（或其他实体）可以执行，并与系统的参与者进行交互。 (ISO/IEC 23643:2020)
漏洞可利用交换 (VEX)：关于特定产品中漏洞状态的机器可读断言。
漏洞：资产或控制的弱点，可以被一个或多个威胁利用。 (ISO/IEC 27000:2018)
漏洞管理：识别、分类、确定优先级、修复和缓解软件漏洞的循环实践。
SBOM 框架概述
在较高层面，SBOM 内容由 MDM 收集，并存储在软件组件存储库中（参见“NTIA 软件供应商指南：SBOM 生产和提供”）。 随后，MDM 编译并生成设备 SBOM，并将其发布供 HCP 使用。 下面的部分提供了从 MDM 和 HCP 的角度，关于生成、分发和导入 SBOM 的更详细信息。
图 1 显示了一个高层框架，其中通过 MDM 和 HCP 之间的 SBOM 生成/导入，实现了信息共享和增强软件透明度。 在这个框架下，既考虑了 MDM，也考虑了 HCP 的需求。
图 1：SBOM 的高层框架
制造商考虑概述
本部分概述了 SBOM 的 MDM 考虑因素，包括收集 SBOM 内容、生成 SBOM、分发 SBOM 以及维护 SBOM 内容（包括漏洞监控和变更管理）。需要注意的是，设备 SBOM 本身不会被维护，因为新的设备 SBOM 会与新的产品版本一起创建和发布。但是，从最终用户（即接收到新设备 SBOM 的用户）的角度来看，这实际上是旧设备 SBOM 的更新。只有在维护与 SBOM 内容相关的文档和流程时，才能进行此更新。术语“维护 SBOM 内容”以及对该描述的意图，在图 2 中进一步说明。
在软件开发生命周期（SDLC）的各个阶段（如设计、代码构建-测试），各种类型的软件组件会被整合到医疗设备中。这些组件的 SBOM 内容应在 MDM 软件组件存储库中收集和存储，并与其他相关信息一起作为配置管理活动的一部分。SBOM 应从该存储库生成并分发给 HCP，作为部署/发布阶段的活动。HCP 可以在此处获取 SBOM，即在采购过程中或软件发布时。在发布 SBOM 后，漏洞监控可以触发对相关软件组件的变更控制，然后反馈到 SBOM 内容的收集和软件组件存储库中。图 2 提供了关于 SBOM 在 SDLC 跨各个阶段的管理方面的更详细信息。
图 2：SBOM 在软件开发生命周期（SDLC）中的管理
收集 SBOM 内容
SBOM 内容的收集始于 SDLC 的设计阶段。SBOM 内容可以来自各种来源，包括：
专有的软件开发文档；
商业软件供应商提供的第三方 SBOM 文档；
开放源代码软件提供的文档，或
软件组合分析 (SCA) 工具生成的输出。
适用的 SBOM 内容在设计-代码-构建-测试阶段收集，然后存储在 MDM 软件组件仓库中。需要收集的医疗设备系统 SBOM 内容，包括属于医疗设备系统的外围设备中的组件。这可能需要不同的来源和工具。例如，可以使用扫描产品 SCA 工具来识别相关组件。 另一种方法是，对于诸如固件、嵌入式软件和可编程逻辑控制器 (PLC) 等组件的供应商，可以提供 SBOM，以便 MDM 将其纳入软件组件仓库中。
有关可能包含在 MDM 软件组件仓库中的组件类型以及用于收集这些内容的工具的更多详细信息，请参见附录 9.1。
生成 SBOM
为了生成 SBOM，制造商需要考虑整个软件供应链。 要生成 SBOM，应将适用的 SBOM 内容聚合到每个产品发布和产品更新的设备 SBOM 中。 每个产品发布和产品更新的最终设备 SBOM 应该被维护并可供分发。 SBOM 的生成应遵循明确且已建立的方法，以确保输出的一致性。 因此，SBOM 在整个设备生命周期中都会进行更新和维护。
以下部分描述了 SBOM 元素和格式的考虑因素。 更多关于 SBOM 生成和工具的信息，请参见 NTIA 的“SBOM 生成指南”。
SBOM 元素和格式
每个 SBOM 条目应包含用于识别每个软件组件的信息。可包含在 SBOM 条目中的信息可能有所不同，但总体而言，SBOM 应该尽可能完整，因为 SBOM 的深度会影响其实用性。 访问更完整的信息有助于更快地识别和评估漏洞，从而提高医疗设备的网络安全。 遵循 NTIA 的建议，对于医疗设备的网络安全，一个基本的 SBOM 应包含以下元素：
作者姓名：指创建 SBOM 文件的实体（即个人、组织或类似实体）。
时间戳：记录 SBOM 数据组装的日期和时间。
软件组件供应商：负责创建、定义和识别组件的实体。 软件组件供应商的名称通常应指用于商业软件的法定商业名称。
软件组件名称：由原始供应商分配给软件单元的标识。
软件组件版本：供应商用于指定软件从先前标识的版本中的更改的标识符。
唯一标识符：用于标识组件或用作相关数据库查找键的标识符。
关系：描述“上游组件 X 包含在软件 Y 中”的关系。
SBOM 中包含的元素具有基本信息，从而可以识别它们。 还可以将其他信息添加到 SBOM 中，作为额外的元素或作为核心 SBOM 的补充，根据需要。 例如，建议使用组件哈希，因为它有助于将组件的存在与相关数据源进行映射。 此外，与设备生命周期相关的信息（例如，软件组件的不再支持日期），也可以作为补充信息提供，因为它有助于在 TPLC 范围内进行医疗设备风险管理。
除了考虑需要包含的基本元素外，医疗设备制造商（MDMs）还需要考虑 SBOM 的格式。 目前，有几种自动化的 SBOM 格式：CycloneDX、软件包数据交换 (SPDX) 和软件识别 (SWID)。 关于这些格式的更多信息，包括 SPDX 和 SWID 的详细医疗设备示例，可以在 NTIA 的“SBOM 生成指南”中找到。
分发 SBOM
SBOM 的分发是指将 SBOM 信息从制造商转移到医疗保健专业人员 (HCP) 或用户的过程。 制造商必须考虑如何最佳地分发其 SBOM，包括提高意识、提供访问权限和推送更新。 这可以是电子文件或产品或制造商网站上的应用程序编程接口 (API)。 尽管目前没有一种最佳的 SBOM 分发方法，但鼓励使用标准化的自动化发现和交换机制。
首先，医疗保健专业人员需要意识到 SBOM 的存在。 应该将 SBOM 作为采购过程的一部分，最初提供给医疗保健专业人员。 例如，这可以包含在产品的客户安全文档 (IMDRF/CYBER WG/N60FINAL:2020)、医疗器械安全制造商披露声明 (MDS2, ANSI/NEMA HN 1-2019) 或共享通信渠道 (例如发布/订阅系统) 或医疗器械上的发布接口中。 鉴于医疗器械的频繁更新，应鼓励采用标准化的网络方式，以便医疗保健专业人员可以轻松识别产品和软件版本，从而支持自动更新。
其次，制造商应使 HCP 能够分发或访问 SBOM。 现有的方法通常分为以下三类：
SBOM 直接从制造商提供给 HCP；或
SBOM 存储在医疗器械上；或
HCP 可以通过存储库访问 SBOM。 一个 SBOM 存储库包含来自不同产品的 SBOM，这些产品可能是来自同一制造商或不同制造商。
一个由制造商管理的存储库仅包含来自单个制造商的设备 SBOM，而一个中心化的存储库包含来自多个制造商的设备 SBOM。
集中式存储库可能由第三方服务管理，也可能由医疗服务提供商管理（即，医疗服务提供商可以将来自制造商的设备 SBOM 聚合到一个集中位置，以便更方便使用）。有关医疗服务提供商管理的存储库的考虑，请参见第 6.1.1 节。
虽然这并非详尽的清单，但以下表格概述了 MDM 应考虑的 SBOM 分发方法的优缺点：
表 1：某些 SBOM 生成方法的优缺点
| 分发方法 | 优点 | 缺点 |
|---|---|---|
| 包含在制造商的客户安全文档中 |
- 不需要专门的工具
|
不是自动化的
文档必须经常更新并分发给用户
需要一种方式将文档与设备本身关联起来（强大的资产管理）
对 SBOM 的访问控制较少
由制造商作为单独（电子）文档提供 |
不需要专门的工具
对 SBOM 的访问控制更多
最好是机器可读
|
不是自动化的
文档必须经常更新并分发给用户
需要一种方式将文档与设备本身关联起来（强大的资产管理）
通过显示屏、参考或下载从医疗设备获取|
始终是正确的版本
由用户控制
对 SBOM 的访问控制更多
|
不是自动化的
需要访问设备才能访问信息
设备可能没有提取信息的手段（例如，用户界面、USB端口、网络连接）
需要设备上的足够空间
可能需要使用额外的电池容量（在电池供电的医疗设备中）
通过医疗设备上的API获取|
对 SBOM 的访问控制更多
可以用于自动化流程
|
API标准尚未定义
需要工具
需要连接
制造商管理的数据存储库|
对 SBOM 的访问控制更多
可以用于自动化流程
|
- 客户需要检查多个制造商网站/存储库以获取信息
集中式存储库|
客户获取信息更便捷的方式（即，不需要检查多个单独的制造商网站/存储库）
可以用于自动化流程
|
制造商在使用第三方服务时，需要考虑知识产权、责任以及其他相关问题
版本管理方面存在挑战，因为一些组织可能拥有同一设备的多个版本，具有不同的更新状态，因此需要访问所有相关的SBOM，而不仅仅是最新版本
[Glossary - use these exact translations when these terms appear:] 差距分析 -> Gap Analysis test_zh -> test_en
在 SBOM 分发的另一个考虑因素是保护 SBOM 信息。医疗设备 SBOM 应被归类为敏感/机密信息，符合行业最佳实践。从 MDM 到外部接收者、监管机构和医疗保健专业人员的沟通渠道，需要支持保护措施，以帮助降低这些文档被泄露的可能性，从而降低风险。此外，这些外部组织（即设备 SBOM 的接收者）需要维护严格的内部安全政策和实践，以保护 SBOM 的完整性、真实性和保密性。
维护 SBOM 内容
SBOM 并不明确说明某个软件组件是否存在漏洞。但是，SBOM 可以与其他资源一起使用，以监控医疗设备中的漏洞。MDM 可以通过漏洞可利用交换 (VEX) 向医疗保健专业人员通知漏洞信息的一种方式。
在医疗设备的生命周期中，每个利益相关者都依赖于有关第三方软件组件的准确和最新的信息。MDM 可以使用 SBOM 来识别、评估和缓解与设备上的软件漏洞相关的潜在患者安全风险。医疗保健专业人员可以使用 SBOM 来在购买和部署设备时进行评估，以便他们与制造商合作管理网络安全风险。
漏洞监控可以在确定需要对相关软件进行更改时触发变更控制事件。MDM（管理机构）应利用现有的变更管理控制（即，用于识别、记录和授权对IT环境的更改的流程），以确保对设备软件的任何更改都记录在SBOM中，并采取适当的后续行动。最终，任何SBOM内容的变更都应生成更新后的设备SBOM，并分发给相关利益相关者，其中包含已更改的组件。
SBOM与变更管理
[术语表 - 在这些术语出现时，请使用这些确切的翻译:] 差距分析 -> Gap Analysis test_zh -> test_en
虽然软件开发生命周期 (SDLC) 已在近年来整合到医疗器械开发的预后和售后变更管理流程中，但对于许多制造商来说，第三方组件的变更管理仍然是一个新兴领域。重要的是要理解，任何导致设备软件发生变更的事件都应导致新的 SBOM。这些事件包括但不限于：
通过升级、更新或补丁修复漏洞，
向医疗器械软件添加新功能，
将一个软件组件替换为另一个组件，
添加或删除软件组件，
由于设备硬件或其操作系统中第三方组件的生命周期结束 (EOL) 或不再提供支持 (EOS) 决策、安全补丁或新版本上市而引起的变更，
变更控制应适用于 SBOM，包括专有的医疗器械软件和第三方软件库。这些信息不仅对内部版本控制很重要，还可以帮助医疗器械制造商 (MDM) 告知医疗保健专业人员 (HCP) 已经采取了缓解措施。
应定期向 HCP 沟通 SBOM 的变更，并以可操作和可供机器读取的格式在适当的发布平台上提供。
挑战
SBOM 在通过软件透明度来提高患者安全方面具有巨大的潜力。在预后和售后活动中生成、监控和分发全面的 SBOM 可能会给 MDM 带来挑战。需要充分的工具和内部流程。
本部分重点介绍了在 SDLC 中实施 SBOM 的一些挑战。
* * 1. **已上市/旧设备上的 SBOM：** **SBOM 是一种相对较新的概念，并且仍在被采用中。一般来说，为过去生产的旧设备生成 SBOM 可能会遇到困难，难以获得包含基本信息和元素的 SBOM。医疗器械制造商应根据实际情况，合理使用第三方供应商提供的 SBOM，包括如何使用成分分析工具来补充这些 SBOM，尤其是在第三方供应商提供的信息不可用时。尽可能构建一个 SBOM，即使其范围和深度有限，尤其是在它涵盖主要软件组件，如操作系统、COTS 软件和开源软件时。这可以扩展和改进 SBOM 的核心内容。这可以通过 HCP 或其他方的各种工具来实现。医疗器械制造商应仔细选择最适合组织需求的工具（例如，提供对医疗器械制造商业务相关风险的最佳见解）。某些 SCA 工具可以生成符合要求的 SBOM。SCAs 还可以进一步确认编译器设置是否设置为促进安全性/加固，确定编译器是否避免了包含漏洞的代码、意外地包含系统网络工具以及包含包含调试信息的文件的存在。**
- 标准和工具： SBOM 的收集、生成、分发和使用，可以借助标准和工具。以下提供了有关标准和工具的高层考虑，关于使用工具收集 SBOM 内容的详细信息，请参见附录 9.1。对软件和作者的稳定、全球识别需要进一步澄清。国际标准是指定最先进技术的途径。
标准和工具仍在不断发展和完善；医疗设备制造商（MDM）不应等到这些“最终确定”后再采取行动。相反，MDM应生成初步的SBOM，并应用基本的/基础的SBOM概念。例如，虽然可能存在用于识别SBOM内容的工具，但将这些内容转换为可供机器读取的格式以及识别受影响的组件（如美国国家标准与技术研究院（NIST）的国家漏洞数据库（NVD））可能会带来挑战。漏洞数据库会随着时间的推移而变化，并且可能不完整。
随着越来越多的组织继续努力定义标准和工具，在中期和长期，MDM可能能够将SBOM迁移到新的平台上。
* 1. **SBOM 的深度：** SBOM 可以是动态的，并且会随着时间的推移而变化，因为 SBOM 是针对每个产品发布或更新而创建的。定义合适的 SBOM 内容深度，并将其包含在 SBOM 中，将影响维护 SBOM 所需的资源数量和类型。更深度的 SBOM 将生成更高质量的 SBOM，并为最终用户提供更高的价值。然而，随着深度增加，生成和分析 SBOM 也会带来更大的复杂性和挑战。
- SBOM 分配： 承认，在分配 SBOM 方面存在许多挑战。这些挑战包括但不限于：(a) 软件更新的频率 (b) 相应的 SBOM 更新需求 (c) 需要在用户资产管理系统中维护分布式 SBOM。医疗保健提供者（HCP）可能拥有同一设备的多个版本，具有不同的配置，或者在不同时间更新到新的软件版本。HCP 需要针对每个设备拥有适当的 SBOM。
医疗保健提供者考虑概述
医疗环境在过去十年中实现了数字化，并且数字技术已渗透到医疗行业的各个方面。这场数字转型导致对软件和基于软件的设备在执行行政和临床功能方面产生了依赖。不幸的是，这种数字化与网络安全威胁的急剧增加同时发生。由于医疗保健领域越来越依赖和互联，这影响了包括大型医疗系统、小型农村设施以及不断增长的门诊服务（包括居家护理）在内的各种医疗保健实体。
制造商应为他们的产品提供软件材料清单（SBOM）。本部分概述了医疗组织在SBOM方面需要考虑的内容，包括获取和处理SBOM。请参阅图 1，了解SBOM的总体框架。
SBOM 的获取和管理
SBOM 被用于医疗保健领域的风险管理，从采购开始。医疗保健提供者应要求制造商为任何打算集成到其网络基础设施中的设备提供 SBOM。为了能够利用 SBOM，组织应确保具备获取 SBOM 的能力。对于医疗保健实体来说，拥有完整且准确的资产清单至关重要。该清单应包含最新的医疗设备清单，包括唯一的设备标识符，从而可以与其他的资产管理系统和资产丰富数据源（如 SBOM）进行关联。医疗保健实体需要了解其网络上的硬件资产以及运行在其中的软件。一旦获取了 SBOM，应对其进行管理，以最大限度地提高组织的效益。
本部分提供关于医疗组织对 SBOM 的考虑，包括获取和管理 SBOM，以及针对医疗服务提供商管理的 SBOM 存储库的具体考虑。
获取和管理 SBOM 的考虑
医疗服务提供商 (HCP) 需要了解网络环境中存在的硬件资产、相关软件以及软件即医疗器械 (SaMD)，并了解其运行状态。 HCP 可以利用现有的信息技术和资产管理实践来盘点直接从开发者处购买或定制开发的软件。 然而，在购买的设备上运行的软件无法通过这些已建立的实践进行盘点。 SBOM 是一种提高 MDM 和 HCP 之间透明共享信息的手段。 以下是与 SBOM 和医疗服务提供商管理的 SBOM 存储库相关的考虑。
采购：SBOM 可以在采购过程中提供，从而使 HCP 能够审查设备组件。 HCP 应了解，在采购和交付之间，SBOM 可能会发生变化。
标准格式和交付：SBOM 的交付应通过标准格式和自动化分发和获取机制进行。 这使 HCP 能够高效地获取信息并将其存储在安全的位置，以保护数据的完整性。 值得考虑的三种主要格式包括 CycloneDx、SPDX 和 SWID。
唯一设备标识符：理想情况下，设备 SBOM 应与一个唯一的标识符相关联，以便能够准确地将 SBOM 与每个设备相关联，因为 HCP 可能会拥有多个型号和版本。 如 IMDRF 的“唯一设备标识符 (UDI) 申请指南”所述，应在产品级别引用唯一设备标识符，以确保正确地将 SBOM 映射到设备和制造商，但还应包括医疗设备软件的版本号或设备本身的版本号（如果适用）。 缺乏对软件和硬件组件的标准唯一标识符可能会导致手动映射。
完整性：SBOM 的完整性水平会影响其可利用的程度。 至少，SBOM 的内容信息应包括作者姓名（公司名称和/或个人姓名）、时间戳、软件组件供应商、软件组件名称、软件组件版本、唯一标识符和关系（参见第 5.2.1 节）。
沟通：当在设备 SBOM 中发现具有已知漏洞的软件组件时，强烈建议 MDM 与 HCP 之间进行沟通，以确保 MDM 采取的措施以及如果需要，由 HCP 的国家/地区机构批准。
增强的设备管理：医疗专业人员需要具备建立和管理内部 SBOM 仓库的能力，并将他们环境中的每个设备与特定的 SBOM 关联，从而实现更有效的设备管理。
搜索和查询能力：该仓库需要具备搜索和查询功能，以便准确地识别和管理医疗专业人员众多设备中的风险，包括已知的漏洞。
医疗专业人员甚至可能希望跟踪购买设备中包含的嵌套软件的级别，从而了解是否存在漏洞。
- 更新和维护：该仓库需要支持在设备整个生命周期内更新和__维护 SBOM 内容，以确保提供准确/最新的信息。为了确保可管理性，需要自动化流程。
由于格式和软件标识符很可能会在设备和仓库的整个生命周期内发生变化，因此，将设备标识符映射到任何格式用于记录 SBOM 信息的文件，是此类 SBOM 仓库最重要的功能（根据 ISO/IEC 19770-2:2015，SWID 标签是一种标记软件的方式）。
- 安全的仓库：SBOM 仓库应具有安全性（例如，基于角色的受限访问权限，仅限医疗组织中需要的人员），以防止恶意人员修改信息或将其用作攻击设备或医疗专业人员网络的路线图。
注意：上述 a-f 条目是通用的 SBOM 考虑因素，并在第 5 节中也进行了讨论，因为这些考虑因素也适用于 MDM。
摄取和管理 SBOM 的方法
SBOM 可以手动输入或通过自动化流程。然而，由于手动流程可能会迅速变得繁琐，因此建议所有规模的医疗保健专业人员采用自动化流程，以减轻管理负担。自动化还可以帮助管理 SBOM，因为 SBOM 可能会随着时间的推移而更新。作为医疗保健提供者的运营的一部分，组织可以利用安全信息和事件管理 (SIEM) 软件解决方案，该解决方案可以，在其他方面，收集、存储、汇总和分析来自网络设备、服务器等的。如果 SIEM 可以读取 SBOM 格式，则可以使用这些 SIEM 来导入 SBOM。
为了在一段时间内保持 SBOM 的使用，一些医疗保健组织正在探索将 SBOM 与其供应商风险管理 (VRM) 系统（通过配置管理数据库 (CMDB) 或计算机化维护管理系统 (CMMS）进行链接或集成。在某些情况下，医疗保健专业人员正在探索直接将 SBOM 导入这些技术。还可以使用定制开发的软件工具或脚本来导入 SBOM。对于直接导入以及/或使用定制工具，医疗保健专业人员需要考虑其数据管理系统的电子格式的专有性。
虽然这并非详尽的清单，但以下表格概述了医疗保健专业人员可能用于导入和管理 SBOM 的某些方法及其优缺点。
表 2：某些 SBOM 导入和管理方法的优缺点
| 导入或管理 SBOM 的方法 | 优点 | 缺点 |
|---|---|---|
| SIEM |
- 能够直接导入
|
与 SBOM 格式的兼容性
能够与专有 SBOM 配合使用
搜索访问受限
CMDB/CMMS|
高度可搜索
能够直接导入 (一些供应商参与了NTIA试点——Nuvolo和ServiceNow)
与单个资产的直接关联
|
与 SBOM 格式的兼容性
能够与专有 SBOM 配合使用
VRM
- 可搜索，能够直接导入
|
与 SBOM 格式的兼容性
能够与专有 SBOM 配合使用
缺乏与单个资产的关联
自定义脚本
- 可以根据医疗专业人员的独特需求进行定制
|
可能会耗费大量时间和资源来生成
错误发生率较高
关于管理 SBOM 的特定用例的更多详细信息，请参见第 7.0 节 SBOM 用例。
SBOM 用例
SBOM 在各个利益相关者手中具有广泛的应用。例如，从医疗保健专业人员（HCP）的设备生命周期角度来看，SBOM 在部署、集成、配置、使用、维护和设备配置管理（例如，因为 HCP 可能会拥有同一设备的多个版本，因为设备并非同时更新）方面都有帮助。
SBOM 也可由 MDM 在医疗设备的整个生命周期（从设计阶段到支持结束和报废）中使用。 总体而言，组织可以使用 SBOM 采取更积极的安全立场，涵盖整个设备生命周期。
本节提供了 SBOM 作为辅助工具的用例示例，用于：
风险管理
漏洞管理
事故管理
以下部分提供了这些用例的高层概述。 虽然后续部分主要关注 MDM 或 HCP 的视角，但这些用例也可能适用于其他利益相关者。
资产管理和采购用例在本文件中未包含。 如果您需要有关这些用例的更多信息，请参阅 NTIA 软件组件透明度医疗保健概念验证报告。
风险管理
MDM 的视角
典型的风险管理活动，如 IMDRF 的网络安全指南（IMDRF/CYBER WG/N60FINAL:2020）第 5.2 节中所述。对于 SBOM（软件清单）的生成，制造商需要考虑整个软件供应链。这包括设备中包含的软件组件。通过使用外部漏洞信息来源，SBOM 可以帮助识别这些软件组件中的现有漏洞。当发现有漏洞的软件组件时，将启动风险分析过程，该过程还将考虑软件依赖关系。
依赖关系可能包括诸如库、操作系统、传输控制协议/互联网协议 (TCP/IP) 堆栈以及运行软件和系统的其他组件。以下是利用 SBOM 获益的一些风险管理活动：
风险评估： 结合外部漏洞信息来源，SBOM 可以用于识别潜在漏洞。SBOM 提供有关潜在漏洞的信息，包括其潜在的可利用性和影响。这些漏洞信息可用于估算和评估与特定漏洞相关的风险水平。
风险控制： 监控并定期验证 SBOM 中列出的组件是否存在漏洞，有助于将风险控制在可接受的水平（参见用例 7.2 漏洞管理）。
评估和监控： 根据需要更新 SBOM，以包含新的软件发布
产品生命周期风险管理： 在购买时，向医疗保健专业人员提供以机器可读格式的 SBOM，作为产品安全文档的一部分，并在整个设备生命周期内进行更新（在设备接近EOL时，提供最新的 SBOM，以方便医疗保健提供商的管理）。 参见 IMDRF/CYBER WG/N70DRAFT:2022，获取更多详细信息。
医疗保健专业人员的视角
SBOM 被用于医疗保健专业人员的风险管理，从采购开始。 SBOM 提供关于设备软件包含的内容的透明度，从而可以识别与之相关的潜在风险。 这将使医疗保健专业人员更好地了解设备在其生命周期内的益处和风险，以及如何更有效地应用风险控制措施和缓解策略。
漏洞管理
本节讨论了如何有效利用 SBOM 进行医疗设备漏洞管理的用例和考虑因素。
MDM 的视角
风险管理是 MDM 在上市后策略的关键组成部分，旨在确保其医疗设备保持可接受的风险水平。作为网络安全的一部分，制造商会监控威胁和漏洞信息来源。 SBOM 是一个至关重要的资源，可以用于及时识别潜在的医疗设备漏洞，随着时间的推移，这些漏洞会不断出现和变化。通过使用 SBOM，MDM 可以根据相关漏洞信息，识别可能受到漏洞影响的医疗设备。对医疗设备 SBOM 信息与报告的漏洞中受影响的软件组件信息进行自动比较，可以进一步提高漏洞识别的及时性和准确性。这可以提高制造商进行风险评估、沟通和必要时的修复能力。风险评估的可能结果之一是更换受影响的组件，这最终会导致 SBOM 的更新。
医疗保健专业人员的视角
风险管理是一个重要的过程，使医疗机构能够持续检测、评估和修复 IT 环境中的漏洞。随着每天新漏洞的不断发现，这是一种有效识别和及时修复关键漏洞的方法。本节将探讨各种 SBOM 的使用案例，以帮助医疗保健专业人员（HCP）进行风险管理。
虽然并非详尽无遗，但以下是一些可以从使用 SBOM 中获益的风险管理活动：
监控医疗机构的资产，以应对新漏洞的出现： 可以使用 SBOM 与漏洞信息，以了解医疗设备如何受到新漏洞的影响。 VEX 可能是与漏洞相关的通信机制。
实施临时缓解措施： SBOM 信息使医疗保健专业人员（HCP）能够在 MDM/供应商仍在评估漏洞影响或制定修复方案时，根据需要实施临时缓解措施。
- 建议 HCP 与 MDM 讨论临时缓解措施，因为他们可能对临时缓解措施如何影响医疗器械的使用有更深入的了解。制造商可以使用漏洞可利用性交换（VEX）提供临时缓解措施指导。
产品生命周期管理： SBOM 有助于了解新设备以及现有设备所支持和不支持的软件。这对于 MDM 制定支持时间表很有帮助，以便为 HCP 提供足够的时间来评估风险（包括对企业和患者的影响），如果无法更换设备。
协助医疗保健提供者进行主动安全活动： SBOM 补充了漏洞识别和安全扫描活动，尤其是在扫描不可行或不当的情况下（例如，嵌入式设备、SaMD）。
事故管理
存在多种方法，医生或医疗保健专业人员可能会意识到可能影响医疗设备的安全事件。无论他们如何意识到，SBOM（软件清单）是多个可以帮助医生和医疗保健专业人员在五阶段的事件管理过程中更好地管理网络安全事件的资源[1]，当与完善的事件响应流程结合使用时。对于医生，SBOM 仓库可以缩短识别和评估受影响设备的所需时间。对于医疗保健专业人员，SBOM 仓库可以帮助一线支持团队和网络安全团队采取行动。具体而言，该仓库可以改善对信息进行系统收集、关联和评估，从而检测与网络安全相关的事件，从而最终提高事件处理能力。总而言之，这种改进的响应可以降低因不完整风险评估和数据丢失而导致的风险，从而避免证据被销毁。
参考文献
IMDRF 文档
软件作为医疗设备：风险分类的可能框架及其相关考虑 IMDRF/SaMD WG/N12:2014 (2014年9月)
医疗器械和体外诊断医疗器械的安全性与性能基本原则 IMDRF/GRRP WG/N47 最终版：2018（2018年11月）
医疗设备网络安全原则和实践 IMDRF/CYBER WG/N60：最终版：2020（2020年4月）
遗留医疗设备网络安全原则和实践 IMDRF/ CYBER WG/N70 最终版：2023（2023年4月）
标准
AAMI TIR57:2016 医疗器械安全——风险管理原则
AAMI TIR 97:2019，医疗器械安全——制造商的上市后风险管理
ANSI/NEM HN 1-2019，医疗设备安全制造商披露声明
IEC 60601-1:2005+AMD1:2012，医疗电气设备 – 第 1 部分：基本安全和基本性能的通用要求
IEC 62304:2006/AMD 1:2015，医疗器械软件——软件生命周期流程
IEC 62366-1:2015，医疗器械 - 第 1 部分：将可用性工程应用于医疗器械
IEC 80001-1:2010，包含医疗器械的 IT 网络中的风险管理 - 第 1 部分：角色、责任和活动
IEC TR 80001-2-2:2012，包含医疗器械的 IT 网络中的风险管理 - 第 2-2 部分：关于披露和沟通医疗器械安全需求、风险和控制的指导
- IEC TR 80001-2-8:2016，包含医疗器械的 IT 网络中的风险管理——第 2-8 部分：应用指导——关于 IEC 80001-2-2 中识别的安全能力的标准指导
ISO 13485:2016，医疗器械——质量管理系统——用于监管目的的要求
ISO 14971:2019，医疗器械——将风险管理应用于医疗器械
ISO/TR 80001-2-7:2015，包含医疗器械的 IT 网络中的风险管理——应用指导——第 2-7 部分：关于医疗保健提供机构（HDO）如何评估其符合 IEC 80001-1 的指导
ISO/IEC 27000 系列 - 信息安全管理系统
ISO/IEC 27035-1:2016，信息技术——安全技术——信息安全事件管理——第一部分：事件管理原则
ISO/IEC 27035-2:2016，信息技术——安全技术——信息安全事件管理——第二部分：事件响应规划和准备指南
ISO/IEC 29147:2018，信息技术——安全技术——漏洞披露
ISO/IEC 30111:2013，信息技术——安全技术——漏洞处理流程
ISO/IEC 5962:2021 信息技术 — SPDX® 规范 V2.2.1
ISO/IEC 19770-2:2015 信息技术 — IT 资产管理 — 第 2 部分：软件标识标签
ISO/TR 24971:2020，医疗器械——应用 ISO 14971 的指导
UL 2900-1:2017，适用于可连接网络的产品的软件网络安全标准，第1部分：通用要求
UL 2900-2-1:2017，适用于可连接网络的产品的软件网络安全标准，第2-1部分：医疗保健和健康系统可连接组件的特定要求
监管指导和草案指导
ANSM (草案)：医疗器械在生命周期中集成软件的网络安全（2019年7月）
中国：医疗器械网络安全审查的预先审查指南（2022年3月）
欧盟委员会：2017/745号关于医疗器械的欧盟议会和理事会法规，于2017年4月5日通过，修订指令2001/83/EC、法规（EC）第178/2002和（EC）第1223/2009，并废除理事会指令90/385/EEC和93/42/EEC（2017年5月）
欧盟委员会：2017/746号关于体外诊断医疗器械的欧盟议会和理事会法规，于2017年4月5日通过，并废除指令98/79/EC和委员会决定2010/227/EU（2017年5月）
医疗设备协调组 (MDCG) 2019-16：医疗设备网络安全指南 (2019 年 12 月) https://ec.europa.eu/docsroom/documents/41863/attachments/1/translations/en/renditions/native
FDA (草案)：医疗设备网络安全：质量系统考虑和预上市提交内容 (2022 年 4 月) [本 N73 发布的时，此指南为草案，不适用于实施。它将被最终指南取代。]
FDA：包含离架软件的联网医疗设备网络安全 (2005 年 1 月)
FDA：为家用设备设计的考虑 (2014 年 11 月)
FDA：医疗设备网络安全后的管理 (2016 年 12 月)
德国：联网医疗设备网络安全要求 (2018 年 11 月)
加拿大卫生部：医疗设备网络安全预上市要求 (2019 年 6 月)
日本：确保医疗设备网络安全：PFSB/ELD/OMDE 通知第 0428-1 (2015 年 4 月)
日本：确保医疗设备网络安全：PSEHB/MDED-PSD 通知第 0724-1 (2018 年 7 月)
新加坡标准委员会技术参考 67：医疗设备网络安全 (2018)
TGA：医疗设备网络安全 - 消费者信息 (2019 年 7 月)
TGA：为行业提供的医疗设备网络安全指导 (2019 年 7 月)
TGA：为用户提供的医疗设备网络安全信息 (2019 年 7 月)
其他资源和参考
- NTIA 常见问题解答
https://www.ntia.gov/files/ntia/publications/sbom_faq_-_20201116.pdf
- NTIA “软件组件透明度框架：建立通用软件物料清单 (SBOM)” 第二版
https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf
- NTIA “软件组件透明度框架：建立通用软件物料清单 (SBOM)”
https://www.ntia.gov/files/ntia/publications/framingsbom_20191112.pdf
NTIA “供应链中 SBOM 的角色和益处” https://www.ntia.gov/files/ntia/publications/ntia_sbom_use_cases_roles_benefits-nov2019.pdf
NTIA 医疗保健领域 SBOM 概念验证报告
https://www.ntia.gov/files/ntia/publications/ntia_sbom_healthcare_poc_report_2019_1001.pdf
- NTIA 医疗保健领域概念验证 “SBOM 生成指南”
https://www.ntia.gov/files/ntia/publications/howto_guide_for_sbom_generation_v1.pdf
- NTIA 漏洞-利用交换 (VEX) 概述
https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf
- NTIA 软件供应商指南：SBOM 生产和提供
商务部，根据第 14028 号行政命令“改善国家网络安全”的 SBOM 最小元素 https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf
OASIS 规范 5：VEX
https://docs.oasis-open.org/csaf/csaf/v2.0/csd01/csaf-v2.0-csd01.html#45-profile-5-vex
- CERT® 协调漏洞披露指南
https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
- NIST 网络安全框架
https://www.nist.gov/cyberframework
- NIST 的安全软件开发框架 (SSDF)
- NIST SP 800-115:2008，信息安全测试和评估技术指南
https://doi.org/10.6028/NIST.SP.800-115
- 医疗器械与健康信息技术联合安全计划 (2019年1月)
https://healthsectorcouncil.org/wp-content/uploads/2019/01/HSCC-MEDTECH-JSP-v1.pdf
- MITRE 医疗器械网络安全 playbook (2018年10月)
- MITRE CVSS 医疗领域指南
https://www.mitre.org/publications/technical-papers/rubric-for-applying-cvss-to-medical-devices
- 医疗行业网络安全实践：管理威胁和保护患者 (HICP)
https://www.phe.gov/preparedness/planning/405d/documents/hicp-main-508.pdf
- 开放网络应用程序安全项目 (OWASP)
https://www.owasp.org/index.php/Main_Page
- 医疗器械安全制造商披露声明 (MDS2)
- 美国国家电信和信息管理局 (NTIA) / 商务部，漏洞披露态度和行为：NTIA 意识和采用小组的研究报告
附录
SBOM 组件类型和工具
SBOM 的内容可以来自各种来源。以下列出了可能包含的组件类型以及用于生成 SBOM 内容的工具示例。
- 第三方软件组件类型
SBOM 中包含的组件类型范围可能取决于多种因素，包括但不限于：MDM 的能力、医疗专业人员的期望、可用的 SBOM 软件的成熟度以及潜在或预期的监管 SBOM 要求。
然而，在管理 SBOM 时，了解不同类型组件的重要性，因为组件可能需要不同的方法和工具来进行库存和运营管理。可以区分以下类型：
与或嵌入在专有医疗设备软件中的第三方软件库。
驻留在操作系统上的虚拟机、操作系统和第三方软件组件，例如驱动程序、数据库软件、管理工具和应用程序框架。
与医疗设备上使用的供应商提供的硬件一起使用的第三方软件组件：固件、嵌入式软件和可编程逻辑控制器 (PLC)。
下一部分将详细介绍这些不同类型组件的 SBOM 库存、运营管理和可用的工具。
- 第三方软件库
在现代软件开发中，使用第三方库的代码量通常远大于制造商自己编写的专有代码，这在单个软件中是很常见的。 编制和管理包含这些库的 SBOM（软件清单）可以通过确保 MDM（制造商数据管理）跟踪和编制所有库的清单，并在每次影响所用库的软件变更时更新这些清单来实现。 这种手动跟踪和更新 SBOM 的做法可以被认为是将 SBOM 使用纳入其开发流程中的一个基本步骤。 随着组织的成熟，它们可能会开始采用更高级的程序，例如自动化，以提高流程的效率和准确性。 举例来说，可以利用现有的开发平台和开发/运维（DevOps）环境。 具体的，可以在开发流程的其中一个或多个阶段（DevSecOps）中集成自动化工具/插件。
SBOM 的优势在于，它能够尽早识别第三方库及其已知漏洞。 尽早发现已知的漏洞，可以促进尽早的修复，并且与晚期发现相比，成本更低。 在开发过程中，将易受攻击的组件替换为无漏洞的组件，可以降低成本，因为在软件开发早期阶段的工作量远小于例如验证和验证阶段。 随着代码接近 SDLC（软件开发生命周期）的最终阶段，代码复杂性和依赖关系也会增加，因此代码重构的范围也会相应减少。 此外，尽早发现还可以在 SDLC 的整个过程中管理 SBOM，即在软件发生任何变更时，都会影响 SBOM 的软件组成。
此类工具或插件分析软件，以检测嵌入式或链接的开源软件，并且有些还可以检测商业第三方软件。它们通常会识别已知的漏洞，例如过时的库，这些库有可用的安全补丁。漏洞监控是 SBOM 内容收集过程中的一部分，具体包括：
编码：例如，在执行静态代码分析（即使用工具来突出显示非运行代码中的漏洞）时。
构建：例如，在每个 sprint 结束时构建软件，其中 sprint 是一个特定时间段，在此期间必须完成并准备好审查的工作。
测试：例如，在执行静态应用程序安全测试 (SAST) 时。
这些工具或插件（通常被称为软件组合分析 (SCA) 软件）不需要任何手动输入即可生成 SBOM，但会利用可用的存储库来一般地识别：
软件组件名称
软件组件供应商（供应商）
软件组件版本
组件哈希值
关系（一个或多个依赖层）
组件漏洞
许可模型和合规信息
请注意，除了较大的 SCA 供应商之外，还有其他工具和插件可用，这些工具可以在代码构建和测试过程中使用，并产生类似的结果。虽然有些是免费使用的，从而使所有规模的医疗设备制造商能够实现自动化，但 MDM 应该仔细选择具有最适合其需求的工具。
- 操作系统组件
虚拟机(们)以及医疗设备使用的操作系统是 SBOM 的关键组成部分。 存在一些第三方软件组件，这些组件依赖于操作系统，而设备软件构建在这些操作系统之上，包括数据库软件和应用程序框架，以及用于设备其他关键功能的软件组件，例如安全软件、系统管理工具、远程支持软件和网络组件。
存在多种选项可用于自动化发现和管理操作系统上的第三方软件组件。 一些 SCA（软件成分分析）供应商专注于前文所述的组件，以及操作系统上其他未直接链接或嵌入在专有软件中的软件组件。 但也有专门关注软件资产管理（SAM）的供应商，SAM 是一种管理软件风险和价值的治理实践。
如果这些工具对医疗设备制造商来说不可行，则可以通过执行定制脚本（例如，在 Windows 上使用 PowerShell 脚本或在 Linux 上使用 Bash 脚本）来生成操作系统上的软件库存。 另一种选择是使用漏洞管理扫描工具。 这种方法的优势在于，它还可以提供发现的组件的漏洞信息。
d. 固件、嵌入式软件和PLC
第三方固件、嵌入式软件和PLC是医疗设备生命周期中变化最少的组件，除非发现漏洞。嵌入式软件由主板支持包、二进制驱动程序、软件开发工具包（SDK）、CPU微码和其他库构建而成。这可能高度依赖开源软件。重要的是识别最终产品中包含的所有软件组件。
由于这些类型的软件组件与设备的硬件相关，它们是医疗设备的常规BOM（物料清单）的一部分。BOM是用于制造设备的材料和组件的全面清单，因此包含的不仅仅是软件组件。因此，BOM是管理这些第三方软件组件的良好起点。与SBOM（软件物料清单）类似，常规BOM可以从各种来源获得，包括MDM（医疗设备制造商）的开发活动或第三方提供的BOM。可以使用源代码管理系统和二进制软件组成分析来自动或验证信息的生成。需要注意的是，使用的工具应与嵌入式系统兼容。
如果通过产品生命周期管理（PLM）或企业资源计划（ERP）软件管理BOM，则可以使用导出功能来提取软件组件。如果可用，可以利用固件、软件或PLC供应商的上游SBOM，以增加对第三方组件的深度，如果需要。
如果这些软件组件是专有，例如由医疗设备制造商开发，则应采用与第9.1节“第三方软件库”中描述的相同方法。
- 根据 ISO/IEC 27035，五个阶段包括：
计划和准备
检测和报告
评估和决策
响应
经验教训 ↑