- 前言
医疗设备的数字连接让我们对病人的护理、治疗能够更加有效和高效，且面对各种情况时能有更加直观的数据支持。对第三方组件的利用和依赖使开发此类医疗设备更加经济、更加可靠，并加快了创新的步伐。虽然第三方组件提供了许多好处，但也伴随着一定的网络安全风险。网络安全漏洞的独特之处在于，不同制造商生产的不同医疗设备可能会使用相同的组件，这些看似安全的设备如果使用了这个有漏洞的组件会受到广泛的影响。而且由于设备内的这些通用组件的可追溯性低而变得更加复杂。这样的网络安全风险，有可能影响到病人的安全和联网医疗设备的保密性、完整性和可用性。
为了解决这个全球性的问题，美国国家电信和信息管理局（NTIA）在2018年召开了一个由各利益相关方组成的多部门倡议会来讨论软件透明度问题。其中一项成果是软件物料清单（SBOM）的概念，NTIA将其定义为：一个或多个由组件、其关系和其他相关信息组成的清单。这一倡议为SBOM的发展和国际范围的采用提供了参考。
本文主要讨论SBOM在医疗器械行业的实践，旨在为医疗设备利益相关者医疗设备制造商（MDM）以及医疗服务提供者（HCP）或者监管机构提供SBOM相关及软件透明度实施的更多细节。所以大家如果想要先了解SBOM的基本相关信息的可以看我们的往期相关推文，本文就不再做赘述：
医疗设备SBOM的存在会使得整个TPLC（即产品全生命周期）中都会为医疗设备利益相关者带来好处。对于MDM来说，医疗设备SBOM能够跟踪和为组件的停止维护做好准备（EOL）。如果MDM知道组件及其各自停止维护的日期，MDM就可以更好地为自己和客户准备任何相关的风险，从而提高MDM的质量控制能力；对于HCP来说，SBOM带来的更高的透明度和网络安全信息披露，使得他们可以根据个人的风险状况和网络安全能力来实施网络安全活动，从而更好地评估设备的网络安全风险。
- 理想状态下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 Ⅱ发出。
- 制造商需要关注的事项概述
本节概述了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管理
- 1 收集SBOM的内容
SBOM内容的收集始于SDLC的设计阶段。SBOM内容可以来自不同的来源，包括：
专有软件的开发文件
由商业软件供应商提供的第三方SBOM文件
与开源软件一起提供的文件
软件组成分析（SCA）工具所产生的输出物
适用的SBOM内容是在设计-开发-编译-测试过程中收集的，然后在MDM组件库中需要处于被维护的状态且 SBOM内容需要为医疗设备系统收集，在某种程度上甚至作为医疗设备系统一部分的外围设备中包含的组件。这可能需要不同的来源和工具。例如，相关组件可以通过用于扫描产品的SCA工具来识别。另外，PLC供应商也可以提供SBOM，MDM可以将其纳入组件库。
- 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 分发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的完整性、真实性和保密性。
- 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，并在适当的发布平台上提供可操作和机器可读的格式。
- 面临的挑战及总结
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实践指南中涉及制造商的相关注意事项，下篇将为大家带来医疗机构对于SBOM的注意事项及SBOM的实际运用，大家可以关注我们，下期再见！
参考文献：
IMDRF "Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity"：
https://www.imdrf.org/documents/principles-and-practices-soft...
NTIA Healthcare POC “How to Guide for SBOM Generation” ：
https://www.ntia.gov/files/ntia/publications/howto_guide_for_...