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