5.1 固件和嵌入式软件

  我们将这一类别分为几个讨论领域：作为操作系统的固件、嵌入式设备的固件，以及 SBOM 在某些特定设备场景（如医疗设备）中的应用。

Linux 固件

作为操作系统的固件，特别是 Linux 固件，是最容易理解的，但需注意的是，这些 SBOM 非常复杂。Linux 实际上是由数千个软件产品拼凑而成的操作系统。因此，要获得所需的透明度来了解这些软件可能会很有挑战性。但这是该领域中较容易解决的问题之一。我们为 Linux 看到的许多工具往往只是运行一个 Red Hat Package Manager（RPM）命令，除非通过大规模逆向工程处理映像，或在构建过程中在每个软件对象级别生成 SBOMs。现实情况是，由于 Linux 操作系统的构建方式存在如此多的碎片化，依赖单一实体来产生高保真度的可见性可能是一个挑战。

实时操作系统固件

实时操作系统（RTOS）固件通常更具挑战性，因为传统意义上的 RTOS 并没有文件系统。很多情况下，RTOS 更像是一个二进制文件，而不是像 Linux 风格的固件映像。对 RTOS 作者来说，这是一个可以解决的问题，我们过去也见过 VxWorks 的公共 SBOMs。然而，对于某些工业控制系统的遗留或专有 RTOS（如不使用 QNX 或 VxWorks 的系统），这个问题常常是个盲点。逆向工程可能是处理遗留软件或供应商无法提供必要可见性时唯一可行的方法。

嵌入式系统

嵌入式固件通常是高度优化的小代码。可能是运行在系统芯片（SoC）上的代码，或系统 BIOS。这些代码常常是低级代码，人类很难理解这些固件的分析。此外，为了优化和减少固件的内存占用，许多字符串和符号被剥离，这使得传统的软件组件识别方法变得非常困难。结合高安全区（如可信执行环境，TEE），这些代码运行在一个受保护的区域，不仅增加了安全性，还增加了理解软件功能和运行位置的难度。这在尝试了解软件组件的可利用性或对手如何影响软件执行时尤为明显。

设备特定的 SBOM

在考虑 SBOM 在高度监管环境中的应用时，尤其是医疗设备，需要注意认证是针对设备层面进行的。美国食品药品监督管理局（FDA）可以将胰岛素泵认证为设备，医疗设备的 SBOM 通常只有一层深度。这通常更像是软件库存而非完整的 SBOM。由于这些设备受到高度监管，变化发生得不频繁，SBOM 和分析结果通常比较静态。但令人担忧的是，这些设备的功能有时可能不太依赖于设备上运行的代码，而是依赖于云基础设施和其他外部依赖项，这对很多物联网（IoT）设备尤其如此。这些设备的外部应用程序编程接口（API）、分布在全球的支持基础设施或其他外部依赖项带来了显著风险。尽管这些设备看起来技术上很成熟，但输入和信任关系的变化创造了一个软件透明度和供应链使用案例的盲点。此外，不同设备接收更新的情况也带来了挑战。有些设备可能通过无线网络、互联网或 USB 闪存盘接收更新，这可能导致相同型号的设备在任何给定时间具有不同的 SBOMs。