组织机构可使用该指南评估和衡量与软件生命周期相关的安全实践；推荐的实践可应用于软件供应链的采购、部署和运营阶段。该文档评估称软件供应链中的未被缓解的漏洞可造成重大风险。

ESF 的负责人 Jorge Laurel 在一份媒体声明中表示，“从根本上来讲，SBOM 为客户提升补丁和漏洞管理提供了重要的软件透明度，并缓解了供应链风险。最新的ESF 发布提供的 SBOM 使用最佳实践旨在组织机构以及整个供应链的网络安全性。”

该指南基于CISA 在2022年9月份发布的关于软件供应链开发、生产、分发和管理流程推荐实践报告，以提升这些流程的弹性。同时，该指南构建于并支持管理和预算办公室关于通过软件安全开发实践增强软件供应链安全的备忘录。

指南中提到，“鉴于保护软件供应链的因素各不相同，本跟进指南主要关注SBOM使用和开源软件。该信息有助于继续促进不同角色之间以及网络安全专业人员之间的通信，从而提升软件供应链流程中的弹性和安全性。建议所有组织机构都将主动管理和缓解风险作为不断发展的软件安全开发实践的一部分。组织机构作为软件供应链生命周期中的软件开发者、供应商或客户的角色，将继续决定这一责任的形式和范围。”

另外，报告建议，鉴于最近软件供应链事件频发，建议采购组织机构将供应链风险评估分配到采购决策中，“软件开发人员和供应商应当改进软件开发流程并降低不仅是员工和利益相关者，还有用户的风险。”

在SBOM使用方面，组织机构需要关注对不同客户组织机构收到的SBOM的使用，并为将由客户使用的 SBOM 的使用提供指南。SBOM 主要传递的信息与软件构成有关。

指南提到，“单是了解供应商能够提供高质量的 SBOM 对于软件用户而言就有诸多好处，因为这种行为提供了某种程度的信心，说明软件供应商更可能有能力来响应供应链问题。然而，完全利用SBOM的能力要求供应商能够将SBOM数据转化为安全情报，从而推动安全措施。从安全角度而言，SBOM 的价值在于，它确保软件是最新状态并已修复已知的漏洞。”

SBOM 提供的透明度还可解决其它风险，如从SBOM中衍生的许可证信息有助于企业确保他们在使用开源和第三方许可软件时遵循许可要求。

使用应用程序的组织机构也可获得归属信息（如SBOM提供）。这种更大程度的可见性为许可合规提供了另外一个可能的途径。SBOM数据还可提供关于组织机构中组件的更新状态情况，以及组织机未及时更新时存在的技术债务风险。这又有助于了解维护成本以及所有权或未来合同的潜在成本。

该指南还说明了软件客户采购、管理和使用SBOM的工作流，其中包括商业和非商业实体从供应商、开发者或开源采购第三方软件的能力。如果真实的采购会在SBOM 评估之后不久发生，则SBOM可告知与采购产品相关联的风险决策。最初，可通过SBOM的内容（如与SBOM组件相关联的已知漏洞）评估风险，不过随着时间的流逝，由于环境变更或新的 “0day” 漏洞的出现，可重新评估风险。

指南还进一步详述了现有软件产品在软件更新、软件升级后应当提供新的SBOM或者扩充原有的SBOM。应当比对新的/更新后的SBOM和之前的SBOM，识别出上个版本后被引入或被删除的新组件/依赖。应当将这些变化与当前的威胁信息（如CVE和/或 VEX）进行比对，以确定、通知和更新当前的风险态势和风险评分。

该指南还提供了关于如何基于SBOM量化软件产品或组件的风险信息。除了追踪定义明确的已知风险如检查已知漏洞清单外，SBOM数据可用作基于上下文的风险分析的起点。可进一步调查SBOM中提到的组件，了解组件来源详情，如管辖、成熟度（如开源项目仅有一个维护人员等）或者供应商的财务稳定性。虽然该数据可能无法从SBOM中获取，但可作为促进更多增强风险分析的这种信息丰富性的起始点。

风险评分可使组织机构基于所定义的风险因素来了解自身供应链风险并预测企业中某具体软件产品未来可能面临的风险。风险分数用于预测软件和/或其组件目前和未来的风险方面。该衡量通过SBOM中的指标、VEX、SCRM（供应链风险管理）中的其它推送和内容开发而成。

该指南还提到，风险分析和将用于评估产品和/或软件组件评分的标准将包括具有分类定义的说明，以推动评估结果的透明度。指南写道，“当应用或评估风险分数时，软件的使用上下文、软件的访问或隔离方式、所支持的流程和系统都应当是关联风险的考虑项。风险分数提示了一款软件产品或软件组件的整体风险情况。”

要实现SBOM的最大价值，组织机构需要制定相关网络策略和程序，为企业中的所有软件敏捷、自动化地执行SBOM的使用。这与其它安全数据并无不同。例如，威胁情报数据也经历了类似的发展以及累死的成熟度多样性。执行正确的运营流程是最小化通过SBOM内容而可视化的风险的前提。

减少软件相关联风险的一些缓解措施如下：

1、识别易受攻击和/或可利用软件版本，据此对打补丁进行优先级排序。监控这些系统/软件中是否存在恶意或异常行为，判断与这些观察相关联的风险并自动执行正确行为。人工智能/机器学习模型有助于自动化检测恶意或异常行为。

2、 使用收集自SBOM及其分析的数据，并将其直接集成到风险管理流程中，判断组织机构的软件供应链风险和风险容忍度。这意味着也需要应用相应机制，以应用应对措施、缓解措施或其它风险控制活动。

3、按照“零信任”基础架构方法，使用SBOM和SCRM流程。

该指南还提到，四个象限方法是评估COTS软件中开源漏洞的一个有效方法，“例如，含有一些漏洞的软件（这些漏洞被指影响低且可能不会遭利用）仅因为接受低风险级别就能够获准用于采购、更新或维护合同。显然，具有高影响力、高度攻击性的漏洞可能会被拒绝。”

然而，否决对业务产生重大影响的软件通常不可能发生。虽然在 COTS 采购流程中使用 SBOM 数据是一门相对较新的科目，但这里的假设是客户和厂商都会具有提升产品并降低安全风险的良好意愿。这一评估流程可用于所有已部署软件中。

总言之，该指南会评估SBOM使用是最新状态，而且将会演变并扩展，新出现的工具有助于自动化和扩展。当然，直到最近工具才出现。此前SBOM 数据非常稀少，因此没有存在开源软件或专有SBOM使用工具的必要。不同的组织机构将专注于通过软件透明度更好管理的不同风险。

另外，行业仍然在想象用例情况，希望随着SBOM变得更为常见会有更多用例出现。仅仅询问SBOMs 仍然具有价值，准备好SBOM数据有利于相应突发公告。SBOM只是软件供应链安全基础清洁度的一部分，对其它C-SCRM 指南的关注仍然重要。

上周早些时候，CISA 发布文档，说明了可能促使组织机构发布VEX信息的情况和实践，还说明了创建或使用VEX信息的实体。发布VEX信息的决策对于多数供应商而言主要是业务决策，而独立的开源开发人员可能会有更多个人考虑。该文档也强调了影响这一决策流程的因素。

9月，CISA 还发布了供应链风险管理的硬件物料清单 (HBOM) 框架。该文档引入的 HBOM 框架为厂商参与当前或未来产品收购中硬件组件的采购商的一致的、可复用的渠道。这一框架使得采购商能够全面评估和缓解自身供应链中的风险。

本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。

    觉得不错，就点个 “在看” 或 "赞” 吧~