美国商务部发布软件物料清单 (SBOM) 的最小元素（中）

 聚焦源代码安全，网罗国内外最新资讯！

编译：代码卫士

自动化支持

自动化支持（包括自动化生成和机器可读性）可使SBOM的能力扩展至软件生态系统，尤其是组织边界。使用SBOM数据要求具有工具，它是可预测实现和数据格式所必需的。例如，某些机构可能希望将该能力集成到现有的漏洞管理实践中；有些机构可能要求实时审计安全策略的合规性。自动化是这两者的关键点，因此也要求具有常见的、机器可读的数据格式。

虽然单一标准意味着简约有效，但生态系统中存在多种数据格式而且它们被用于生成并使用SBOM。通过开放流程和国际力量，已形成这样一些数据格式细则。除了机器可读外，这些数据格式也是人类可读的，能更好地支持故障排除和创新。更重要的是，这些标准对于核心数据字段而言具有互操作性，而且使用常见的数据句法表示。

用于生成并使用 SBOMs 的数据格式为：

SBOM 必须以其中一种可互操作格式在组织边界中传达。如果出现新的可与其它数据格式兼容的标准细则，那么就应当在SBOM最小元素上下文，把这些标准细则归到自动化支持中。同样，如果广泛认为某种数据格式不再交叉兼容，或者不再得到主动维护并支持SBOM用例，那么就应当将这种数据格式从SBOM最小元素自动化要求中删除。使用专有数据格式的标准也不应当包含在内。这样就能实现基于现有工具实现易于采用、支持未来演变以及可扩展性的要求。

实践和流程

SBOM 不止结构性数据集；将其集成到安全开发生命周期中，组织机构应当遵循某些专注于SBOM使用机制的实践和流程。在任何要求提供或提供 SBOMs 的策略、合同或约定中，都应当明确提出多个元素。其中某些元素（如频率）的要求很直接；在一些情况下（如访问），存在多种实践且正在开发更多实践，因此某些约定具有最小元素要求。

频率。如果软件组件以新版本或发布的形式更新，那么必须创建新的 SBOM 来体现该软件的新版本。其中包括集成已更新组件或依赖的软件版本。同样，如果供应商获悉关于底层组件的新详情，或者希望修正已有SBOM数据中的错误，那么供应商应当发布新的经过修订的SBOM。

深度。SBOM 应当包含所有主要（顶层）组件，并列出其中包括的所有传递依赖。至少，必须列出所有顶层依赖的足够多的详情，以便以递归的方式查找传递依赖。

随着组织机构开始建立SBOM，由于子组件供应商的现有要求，可能无法轻易获取除主要组件以外的深度。对SBOM流程的最终采用将能够在子组件层面通过更深的透明度层级进行更深度的访问。应当注意的是，某些用例要求完整的或基本完整的表。如 “举反证“，证明某既定组件不存在于某机构网络中。

SBOM 消费者可通过传递步骤的数量来指定深度要求。或者也可通过运营术语的方式指定深度要求。可以包括软件属性，如“所有非开源软件“，或者某个功能的所有组件或者复杂程度。组织机构还可以向那些提供并缓解SBOM所列组件中漏洞的一方做出不同要求，鼓励报告深度和完整性。这类标准细则不在最小元素范围内。

已知的未知。对于在SBOM 中未列举出完整依赖表的实例，SBOM 作者必须明确识别出“已知的未知“。即，依赖数据清晰地区分出不含其它依赖的组件和所含依赖不明及不完整的组件。该数据必须集成到自动化数据中。为了避免错误假设，数据的默认解释应为：数据是不完整的；SBOM 数据的作者应当肯定地说明何时已完全枚举组件的直接依赖，或何时组件不含其它依赖。当前，这一信息在依赖关系数据字段中实现。

分发和交付。应当及时地向所需方提供SBOMs，而且必须设置恰当的访问权限和角色。SBOM数据可搭配每个软件实例，或者只能访问并直接映射到所指软件的某个特定版本（例如，通过特定版本的URL）。在软件供应链中共享 SBOM 数据可分为两个部分：如何获悉SBOM的存在和可用性（广告或发现），以及SBOM是如何被具有适当权限（访问）的人员检索或传递给他们。和软件保证的其它领域一样，并不存在一劳永逸的方法。虽然提供SBOM的任何人必须以某种方式提供SBOM并提供理解支持，但可根据现有机制确定。SBOM 交付也可反映软件的性质：位于端点上的可执行文件可通过编译代码的方式将SBOM数据存储在磁盘上，而嵌入式系统或在线服务则拥有在线存储的SBOM数据的指针。

访问控制。很多供应商，包括开源维护人员和广泛可获得软件的供应商，可能认为将SBOM数据公开最符合自身利益。不过其它一些组织机构，尤其刚开始，可能希望SBOM 数据保密且只有特定的客户或用户才能访问。如果需要访问控制，则必须指定相关术语，包括将SBOM数据集成到用户安全工具中的费用和空间。这类标准细则可通过许可、合约或其它现有机制来约束软件本身的使用和权益。鉴于软件许可和合约不尽相同，该标准细则的性质不在本文档讨论范围内。

容错空间。最后的实践是容错空间，它应当内置于SBOM的初始实现阶段，允许遗漏和错误。如很多评论人员注意到的那样，虽然内部管理供应链数据可能是一种最佳实践，但它仍在发展过程中。拜登政府将SBOM列为推动软件保证和供应链风险管理的优先任务，因此马上就做比等待完美更好。鉴于还不完美，因此SBOM客户应当明确容忍偶然的无心之过。这样做有助于不断改进工具：供应商发现之前SBOM中的问题时应当提供更新版数据，客户应当接受好意的附件和修订而不是实施处罚，以此鼓励SBOM数据更新。如之前在“频率”部分提到的那样，当获悉新数据时，应当发布更新版SBOM数据。值得注意的是，有意混淆或无知不应得到容忍。

（未完待续）