- 前言
医疗设施的数字连贯让咱们对病人的护理、医治可能更加无效和高效，且面对各种状况时能有更加直观的数据反对。对第三方组件的利用和依赖使开发此类医疗设施更加经济、更加牢靠，并放慢了翻新的步调。尽管第三方组件提供了许多益处，但也随同着肯定的网络安全危险。网络安全破绽的独特之处在于，不同制造商生产的不同医疗设施可能会应用雷同的组件，这些看似平安的设施如果应用了这个有破绽的组件会受到宽泛的影响。而且因为设施内的这些通用组件的可追溯性低而变得更加简单。这样的网络安全危险，有可能影响到病人的平安和联网医疗设施的保密性、完整性和可用性。
为了解决这个全球性的问题，美国国家电信和信息管理局（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_...