SBOM 喊话医疗器械网络安全：别慌，我罩你！ Part Ⅰ

1. 前言

医疗设备的数字连接让我们对病人的护理、治疗能够更加有效和高效，且面对各种情况时能有更加直观的数据支持。对第三方组件的利用和依赖使开发此类医疗设备更加经济、更加可靠，并加快了创新的步伐。虽然第三方组件提供了许多好处，但也伴随着一定的网络安全风险。网络安全漏洞的独特之处在于，不同制造商生产的不同医疗设备可能会使用相同的组件，这些看似安全的设备如果使用了这个有漏洞的组件会受到广泛的影响。而且由于设备内的这些通用组件的可追溯性低而变得更加复杂。这样的网络安全风险，有可能影响到病人的安全和联网医疗设备的保密性、完整性和可用性。

为了解决这个全球性的问题，美国国家电信和信息管理局（NTIA）在 2018 年召开了一个由各利益相关方组成的多部门倡议会来讨论软件透明度问题。其中一项成果是软件物料清单（SBOM）的概念，NTIA 将其定义为：一个或多个由组件、其关系和其他相关信息组成的清单。这一倡议为 SBOM 的发展和国际范围的采用提供了参考。

本文主要讨论 SBOM 在医疗器械行业的实践，旨在为医疗设备利益相关者医疗设备制造商（MDM）以及医疗服务提供者（HCP）或者监管机构提供 SBOM 相关及软件透明度实施的更多细节。所以大家如果想要先了解 SBOM 的基本相关信息的可以看我们的往期相关推文，本文就不再做赘述：

深度解读 | 关于SBOM最基础元素，你需要知道的（Part I）_开源_安势信息_InfoQ写作社区

深度解读 | 关于SBOM最基础元素，你需要知道的（Part II）_#开源_安势信息_InfoQ写作社区

深度解读|关于SBOM最基础元素，你需要知道的（Part III）_漏洞_安势信息_InfoQ写作社区

医疗设备 SBOM 的存在会使得整个 TPLC（即产品全生命周期）中都会为医疗设备利益相关者带来好处。对于 MDM 来说，医疗设备 SBOM 能够跟踪和为组件的停止维护做好准备（EOL）。如果 MDM 知道组件及其各自停止维护的日期，MDM 就可以更好地为自己和客户准备任何相关的风险，从而提高 MDM 的质量控制能力；对于 HCP 来说，SBOM 带来的更高的透明度和网络安全信息披露，使得他们可以根据个人的风险状况和网络安全能力来实施网络安全活动，从而更好地评估设备的网络安全风险。

2. 理想状态下 SBOM 在医疗器械行业中的框架

下图（图 1）展现了一个医疗器械行业 SBOM 从收集-生成-分发的基本框架，这个框架让信息共享成为可能。基于 MDM（设备生产商）生成 SBOM 然后分发给 HCP（医疗机构）这样的流通模式也能有效提高软件的透明度。这个框架解决了来自 MDM 和 HCP 两方的考虑因素。

图 1：SBOM 的理想状态下框架

在图 1 我们可以看出，各种漏洞信息需要在 MDM（设备生产商）和 HCP（医疗机构）中进行有效交换或流通的基础是双方都需要做一些风险管理以及漏洞管理的动作。对于 MDM 来说，我们需要将自有的一些组件纳入到 MDM 自身的软件源库中，不仅如此，其中也需将一些第三方组织（供应商）的 SBOM 纳入进来，从而方便我们对上游供应商的一些代码或组件进行溯源，当合理有效的对上述提到的自有组件以及第三方组件 SBOM 整合到 MDM 的资源库中后就可以生成一份完善有效 SBOM 清单给到 HCP；而对于 HCP 来说，需要建立一个存放来源于不同 MDM 或者其他产品或系统供应商的 SBOM 库，以方便及时对这些组件进行风险管理从而在出现意料之外的情况时能及时做出应对。

接下来我们就将从 MDM（制造商）和 HCP（医疗机构）两个方面进行更加具体的讨论。本文将主要从 MDM 的视角进行讨论，HCP 视角的我们会在 Part Ⅱ发出。

3. 制造商需要关注的事项概述

本节概述了 MDM 的 SBOM 的相关注意事项，包括收集 SBOM 内容、生成 SBOM、分发 SBOM 以及维护 SBOM 内容（包括漏洞监控和变更管理）。需要注意的是，设备 SBOM 本身不需要维护，因为新的设备 SBOM 是随着新的产品版本创建和发布的。然而，从收到新设备 SBOM 的终端用户的角度来看，它是对以前设备 SBOM 的更新。这种更新的唯一途径是维护 SBOM 内容的相关文件和流程。对 SBOM 的维护主要包含三个部分，即 SBOM 中的组件软件监控、风险评估、变化管理这三个部分。图 2 进一步描述了 "维护 SBOM 内容 "这一术语以及这一描述背后的意图。

在设计-开发-编译-测试的软件开发生命周期（SDLC）阶段，各种类型的组件被纳入医疗设备中。作为 MDM 对产品配置管理的一部分，这些组件的 SBOM 内容应与其他相关信息一起收集并存储在 MDM 组件库中。SBOM 应从该资源库中生成，并在部署/发布阶段及时地分发给 HCP。HCP 可以在采购过程中或在软件发布时获得 SBOM。在 SBOM 发布后，漏洞监控可以触发对相关组件的变更控制，然后反馈到 SBOM 内容收集和组件库中。图 2 提供了关于 SBOM 在整个 SDLC 中的管理的额外颗粒度，接下来我们也会具体的从收集、生成、分发三个阶段来对这些相关的注意事项进行阐述。

图 2：软件开发生命周期（SDLC）的 SBOM 管理

3. 1 收集 SBOM 的内容

SBOM 内容的收集始于 SDLC 的设计阶段。SBOM 内容可以来自不同的来源，包括：

• 专有软件的开发文件

• 由商业软件供应商提供的第三方 SBOM 文件

• 与开源软件一起提供的文件

• 软件组成分析（SCA）工具所产生的输出物 

适用的 SBOM 内容是在设计-开发-编译-测试过程中收集的，然后在 MDM 组件库中需要处于被维护的状态且 SBOM 内容需要为医疗设备系统收集，在某种程度上甚至作为医疗设备系统一部分的外围设备中包含的组件。这可能需要不同的来源和工具。例如，相关组件可以通过用于扫描产品的 SCA 工具来识别。另外，PLC 供应商也可以提供 SBOM，MDM 可以将其纳入组件库。

3. 2 生成 SBOM

对于 SBOM 的生成，制造商需要考虑整个软件供应链。为了生成 SBOM，应将适用的 SBOM 内容汇总到每个产品发布和产品更新的设备 SBOM 中。每个产品版本和产品更新的最终设备 SBOM 应得到维护，并可用于分发。SBOM 的生成应遵循一个明确的、既定的方法论，来确保输出的一致性。基于这些行为，SBOM 才能在设备的整个生命周期中得到更新和维护。

下面描述了 SBOM 元素和格式的注意事项。有关 SBOM 生成和工具的其他见解可在 NTIA 的 How to Guide for SBOM Generation 中找到。

3.2.1  SBOM 的元素和格式

每个 SBOM 条目应包含识别每个组件的信息。可纳入 SBOM 条目的信息可能有所不同，但一般来说，SBOM 应尽可能地完整，因为 SBOM 的深度影响其效用。获得更完整的 SBOM 信息可以更快地识别和评估漏洞，从而为改善设备网络安全提供支持。与 NTIA 的建议一致，对于医疗设备网络安全，一份基本的 SBOM 应包括以下内容：

• 作者姓名：指制作 SBOM 文件的实体（即个人、组织或类似）。

• 时间戳：记录 SBOM 数据装配的日期和时间。

• 组件供应商（供货商）：创建、定义和识别组件的实体。组 件供应商名称一般应指商业软件的合法商业名称。

• 组件名称：源头供应商定义的软件单元的名称。

• 组件版本：供应商用于某个组件与之前版本相比发生变化的标识符。

• 唯一标识符：用于识别组件的标识符，或作为相关数据库的查询键。

• 关系：描述上游组件 X 包含在软件 Y 中的关系。

   

包含在 SBOM 中的元素由（组件的）基本信息组成，这些基本信息可以用来方便的进行（组件的）识别。根据需要，其他信息可以作为附加元素添加到 SBOM 中，或者作为核心 SBOM 的补充。例如，组件的哈希值就是一个不错的选择，因为它可以帮助将一个组件与相关的数据源进行映射。此外，与设备生命周期相关的考虑因素（例如，一个组件的终止支持（EOS）日期），可以作为补充信息提供，因为它有助于整个 TPLC 的医疗设备风险管理。

除了考虑要包括的基本元素外，MDM 还需要考虑 SBOM 格式。目前，有几种自动化的 SBOM 格式：CycloneDX、SPDX 和 SWID。关于这些格式的更多信息，比如详细一些的 SPDX 和 SWID 在医疗设备中的实际应用案例等，可以在 NTIA 发布的 How to Guide for SBOM Generation 中找到。

3. 3 分发 SBOM

SBOM 的分发是指 SBOM 信息如何从制造商转移到 HCP 或用户的过程。MDM 必须考虑如何更合适地分发 SBOM，包括提高意识、提供访问和推送更新。可以是一个电子文件或 API 或发布于制造商的网站上。虽然目前没有一种方法可以完美地分发 SBOM，但我们鼓励使用标准化的自动发现和交换机制。

首先，HCP 需要掌握 SBOM。SBOM 作为采购过程的一部分提供在最初就提供给 HCP。例如，这份 SBOM 可以存在于产品的客户安全文件（IMDRF/CYBER WG/N60FINAL:2020）、医疗器械安全的制造商披露声明（MDS2，ANSI/NEMA HN 1-2019）、共享的通信渠道（如发布/订阅系统）或医疗设备的界面上。由于医疗设备更新频繁，应该鼓励建立一种机制，以标准化的方式高效简洁地识别产品和软件版本，从而实现自动更新 SBOM 的可能。

其次，MDM 应该将 SBOM 分发给 HCP 或由其自由访问。现有的方法一般分为三类：

• SBOM 是由 MDM 直接提供给 HCP 的；

• 该 SBOM 直接留存在医疗设备上；

• SBOM 是通过一个储存库提供给 HCP 的。一个 SBOM 库包括不同产品的 SBOM 集合，这些产品可能来自一个或多个制造商。

    【1】制造商管理的存储库只包含单一制造商的设备的 SBOM，而集中式存储库则包含多个制造商的设备的 SBOM。

    【2】集中存储库可以由第三方服务机构管理，也可由医疗机构管理。（即医疗机构可以将他们从制造商那里收到的设备 SBOM 汇总到一个地方，以便于使用）

虽然不是一个详细的清单，但下表概述了 MDM 应该考虑的 SBOM 分发方式的优缺点：

表 1：部分 SBOM 分发方式的优点和缺点

通过上面的表格可以看出，SBOM 的分发基于不同的方式所带来的优缺点也不尽相同。但是就目前来说其实很难有十全十美的一种分发方式，所以对于制造商来说选择“最适合的”才是最重要的，与此同时，从表中我们不难发现访问或者获取的 SBOM 的可控性强弱是分发方式优缺点的一个具体体现。所以这也从某种程度上告诉我们 SBOM 信息的保护是我们在分发过程中必须关注到的。医疗器械 SBOM 应被列为敏感或机密信息，这一行为应该作为行业最佳实践中的一环。从 MDM 到外部接收者、监管者和 HCP 的沟通渠道需要提供一定的保护措施，以帮助减少这些文件被泄露的机会或导致风险暴露的增加。此外，这些外部组织（即设备 SBOM 的接收者）需要建立严格的内部安全政策和实践，以保护 SBOM 的完整性、真实性和保密性。

3. 4 维护 SBOM 内容

SBOM 并不会明确指出一个组件是否有漏洞。然而，SBOM 可以与其他资源一起使用，以监测医疗设备的漏洞。MDM 可能达成的通知 HCP 关于漏洞信息的方式之一就是通过漏洞可利用性交换（VEX）。

在医疗设备的生命周期中，每个利益相关者都需要有关第三方组件的准确和最新的信息。MDM 可以使用 SBOM 来识别、评估和降低与设备上的软件漏洞相关进而对病人造成的潜在风险。HCP 可以使用 SBOM 在购买前和部署期间评估设备，以便他们与制造商合作，管理网络安全风险。

当确定有必要对相关软件进行更改时，漏洞监测可以触发一个更改控制事件。MDM 应该利用现有的变更管理控制（即用于识别、记录和授权 IT 环境变更的流程），确保设备软件的任何变更都被记录在 SBOM 中，并采取适当的后续行动。最终，SBOM 内容的任何变化都应生成一个更新后的设备 SBOM 分发给适当的利益相关者，其中包含被改变的组件。

3.4.1  SBOM 和变更管理（CM）

虽然近年来软件开发生命周期（SDLC）已被纳入医疗设备开发的上市前和上市后的变更管理流程，但第三方组件的变更管理（CM） 对许多制造商来说仍是一个新领域。重要的是要明白，任何导致设备软件改变的事件都应该有一个新的 SBOM 与之对应。这类事件包括，但不限于：

• 通过升级、更新或打补丁来修复漏洞

• 在医疗设备软件中增加新的功能

• 将一个组件换成另一个

• 添加或删除一个组件

• 由于产品的使用寿命到期（EOL）或产品结束更新和服务（EOS）的决定、（安全）补丁或新版本上市，留存在设备硬 件上或其操作系统内的第三方组件发生变化。

变更控制应适用于 SBOM，其中包括专有医疗设备软件和第三方软件库。这一信息不仅对内部版本控制很重要，而且还有助于 MDM 告知 HCP，已经采取了一定的补救措施。对 SBOM 的修改应定期通报给 HCP，并在适当的发布平台上提供可操作和机器可读的格式。

4. 面临的挑战及总结

SBOM 在通过软件透明度提高用户安全方面具很大的前景。不论是在产品发布前或产品发布后，生成、监测和分发完整清晰的 SBOM 对 MDM 来说是一个挑战。适当的工具和内部流程是必要的。以下将为大家强调在整个 SDLC 中实施 SBOM 的一些挑战。

A. 对于已流入市场的设备的 SBOM 应该如何生成？

SBOM 还是一个较新的概念，换句话说也就是仍处于一个被人们逐渐了解和接受的过程中，基于这样的情况我们就会发现已经流入市场的一些设备并没有提供对应的 SBOM，乃至于对这些设备 SBOM 的最基本元素和信息我们都无从得知，所以对于 MDM 来说要去为过去生产的设备准备 SBOM 是具有挑战性的。MDM 应该基于自身的实际情况来选择如何为这些设备去生成 SBOM，哪怕这份 SBOM 的深度和广度都很有限。比如使用适当的 SCA 工具，而且某些 SCA 工具可以生成具有广度和深度的 SBOM，从而方便生产商进行风险管理和漏洞信息的采集或评估。

B. SBOM 的标准和工具应该是怎样的？

一个好的标准和一份好用的工具会使我们对于 SBOM 的生成和后续管理带来很大的便利。尤其是如果能有一个全球都能遵循的标准存在的话能让整个供应链的环境生态都更好。但是这并不意味着 MDM 要“守株待兔”那样等待一份彻底确立的标准与工具的到来，与之相反，MDM 在初期可以基于 SBOM 的基础概念来生成初始 SBOM 这一步反而更加重要，并且尽可能的让这份 SBOM 通过各种方式达到可传输可读的状态，并且找到合适的方式（如 NIST 国家漏洞数据库（NVD））去找到那些容易受到攻击的组件从而进行风险管理。

C. 关于 SBOM 的深度应该是怎样的？

SBOM 的深度是动态的，随着 SBOM 被市场的接受程度越来愈高，以及整个供应链对 SBOM 的要求越来越规范，也会使得 SBOM 的深度逐步提升。但是对于 MDM 来说，一份高深度的 SBOM 往往意味着更多的资源花费，也更有挑战，但是深度越高的 SBOM 也会为终端用户带来更高的价值。

D. SBOM 的分发面临着哪些挑战?

在 SBOM 的分发方面存在许多挑战。这些挑战包括但不限于：

• 软件更新的频率

• 维持 SBOM 更新的相关需求

• 在用户资产管理系统中维护相对分散的 SBOM 的需求

• 一个 HCP 可能有同一设备在不同配置下的多个版本，或在不同时间更新到新的软件版本，而 HCP 需要为每个设备准备适当的 SBOM。 

总而言之，对于 MDM 来说，SBOM 对于医疗器械供应链行业来说，也是相对较新的东西，但不可否认的是 SBOM 的存在会进一步促进医疗器械行业的发展。

本篇文章为主要为大家带来了医疗器械行业 SBOM 实践指南中涉及制造商的相关注意事项，本篇为 Part Ⅰ，Part Ⅱ （下篇）将为大家带来医疗机构对于 SBOM 的注意事项及 SBOM 的实际运用，大家可以关注我们，下期再见！

参考文献：

IMDRF "Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity"：

https://www.imdrf.org/documents/principles-and-practices-software-bill-materials-medical-device-cybersecurity

NTIA Healthcare POC “How to Guide for SBOM Generation” ：

https://www.ntia.gov/files/ntia/publications/howto_guide_for_sbom_generation_v1.pdf