SBOM 和威胁建模
SBOM 和威胁模型回答不同问题。SBOM 识别软件组件和依赖关系。威胁模型解释器械、软件系统、用户、环境或更新路径如何被攻击，以及攻击如何影响安全、性能或网络安全。
SBOM 和威胁模型是不同记录
混淆 SBOM 和威胁模型会削弱两者。组件清单可以显示已知漏洞暴露，但不能说明攻击者是否能到达安全相关功能。威胁模型可以显示攻击路径和控制，但不能替代组件级软件透明度。
NTIA 的 SBOM 框架将 SBOM 描述为正式、机器可读的软件组件和依赖关系清单。因此它是透明度和漏洞管理记录，而不是自动完成的攻击路径分析。
SBOM
记录组件名称、供应商、版本、标识符、哈希、依赖关系和作者信息，使制造商和客户能够跟踪组件暴露和支持状态。
威胁模型
记录资产、行为者、信任边界、数据流、接口、攻击路径、威胁、缓解措施、假设和剩余风险决定。
安全架构
显示认证、授权、加密、日志、更新保护和恢复等控制如何布置在系统和相关服务中。
风险管理
决定剩余风险是否可接受，以及网络安全发现如何影响安全、性能、标签、上市后监督和补救。
上市前文件需要把记录连接起来
FDA 当前上市前指南期望 SBOM、威胁建模、网络安全风险评估、架构和测试证据协同工作。对 section 524B 下的 cyber device，SBOM 是法定提交要素，必须包括商业、开源和现成软件组件。
- 威胁模型应覆盖器械系统、外部实体、部署、互操作、维护、更新、供应链假设和退役。
- SBOM 应包括制造商开发和第三方组件、上游依赖、支持状态，以及评估已知漏洞所需信息。
- 架构视图应说明接口、协议、信任边界、用户、控制、相关系统和更新路径。
- 测试应显示所选安全控制和威胁缓解措施有效，包括相关时的漏洞测试和渗透测试。
当 SBOM 不是孤立表格时，上市前文件会强很多。它应能追溯到威胁模型、安全架构、漏洞分析、测试范围、标签和网络安全管理计划。
上市后记录用于实际运行
发布后，SBOM 和威胁模型变成运行记录。SBOM 帮助识别供应商、开源包、商业组件或操作系统依赖变化时的暴露。威胁模型帮助判断这种暴露在实际器械架构和使用环境中是否会造成患者伤害。
组件 CVE 不会自动意味着器械存在 uncontrolled risk。制造商必须评估版本、配置、可达性、可利用性、补偿控制、安全影响、支持状态和现场器械分布。
当新漏洞、新攻击技术、部署假设变化、新接口、新云服务或更新路径改变风险图景时，应更新威胁模型。
Vulnerability Exploitability eXchange 信息可以帮助说明已知漏洞是否影响产品。它应与证据一起使用，而不是作为笼统声明。客户需要足够信息来应用补偿控制、计划更新并理解剩余风险。
记录质量取决于能否支持决定
有用的 SBOM 和威胁模型必须足够具体，能够支持决定。它们应机器可用、识别版本、发布后维护，并连接到风险管理文件。
NTIA 基线框架识别供应商名称、组件名称、版本字符串、组件标识符、依赖关系、作者名称和时间戳等数据元素。FDA 又增加了器械特定期望，例如软件支持状态、已知漏洞以及与器械风险控制的关系。
医疗器械威胁模型应包括预期功能、资产、行为者、数据流、信任边界、更新流、接口、外部服务、第三方依赖、假设、滥用场景、威胁、缓解措施和未关闭的剩余风险决定。
- 器械不连接互联网，所以网络安全不相关。
- SBOM 没有已知 critical CVE，所以威胁模型已经完整。
- 渗透测试通过，所以不需要解释架构和生命周期控制。
- 客户网络控制所有剩余风险，所以不需要器械标签或验证证据。