什么是 SBOM（软件物料清单）

攻击溯源
2年前

5964748e.jpeg

　　SBOM是一种正式的、结构化的记录。它不仅对软件产品的组件构成进行了详细的说明，同时还描述了这些组件之间的供应链关系。SBOM概述了应用程序中引入的包和库，以及这些包、库与其他上游项目之间的关系。这在重用代码与引入开源代码的时候非常有用。

　　比起软件物料清单，人们似乎对汽车的物料清单更为熟悉。汽车物料清单是一份详细介绍一辆新车中每个组件的文档。汽车供应链是出了名的复杂。即使是丰田和通用汽车公司，它们组装的汽车中，很多零部件也是来自世界各地的分包商。而物料清单则介绍了这些部件的具体来源。当然，这并不仅仅是一些有趣的琐事。如果在某个生产阶段，安全气囊需要被召回，那么汽车制造商就需要一个快捷的方法来获知这些安全气囊的最终位置。

　　尽管软件开发和汽车制造并不是完全相同的工序。但随着越来越多的企业开始使用第三方开源库来开发容器化，分布式的应用，这两个流程的相似度也在逐渐上升。这就是为什么如今对SBOM的使用不断普及。

　　SBOM可以帮助开发人员和用户了解他们开发和使用的软件所包含的内容。这在很多方面，尤其在安全方面，都发挥着重要的作用。

为什么我们需要SBOM？

　　如今，使用原创代码来开发软件的时代已经一去不复返了。现代的应用程序通常是在大量代码重用的基础上，被开发出来的。并且在开发过程中，几乎都会使用到开源库。另一方面，这些应用程序也会被分解为更小的、独立的名为容器的功能组件。这些组件由 Kubernetes等容器编排平台进行管理，在本地或云端运行。

　　总而言之，这些改变对软件开发来说无疑是一个福音，不仅提高了开发人员的生产力，同时也降低了成本。但另一方面，这也同样成为了安全团队的噩梦。由于过于依赖第三方代码，开发人员往往无法完全熟悉软件的内部构成。他们创建了关于软件组件的供应链，并且这些组件就像实体制造商使用的组件一样，极为复杂。同时，由于木桶效应，软件的安全水平往往取决于其内部最为脆弱的那个组件，所以以这种方式开发出的软件往往会存在较为独特的漏洞。目前，行业正在深入解决这些漏洞。

　　2020年以来，一系列能够登上新闻头条的软件供应链攻击相继出现。2020年底，与俄罗斯情报部门相关的黑客们在SolarWinds的网络监控平台设置了后门。随后，使用过该平台的组织全部遭到攻击。此外，2021年底，用于记录系统事件的Java库，Aache Log4j，也被发现存在严重的漏洞。可能会有人认为这是个无关紧要的事件。但是从某种角度上来看，几乎所有的Java程序，多多少少都会涉及到一些对Aache Log4j的使用。结果就是，大量的Java程序同时沦为攻击目标。

　　上述的这些安全危机事件都揭示出SBOM在安全领域的用武之地。许多用户可能对这些漏洞有所耳闻，但却没有意识到自己运行的软件中就包含了Log4j 或 SolarWinds 组件。合适的SBOM，可以帮助组织对自己所部署的包以及这些包的版本有一个确切的了解，从而便于组织根据自己的需要来进行更新，以维护安全。

　　SBOM的用途不仅限于安全领域。例如，它还可以帮助开发人员对不同类型软件组件中包含的开源代码许可证进行跟踪。

关于软件物料清单的行政令

　　SolarWinds事件的发生给全世界都敲响了警钟，尤其是美国政府。因为许多联邦机关都部署了此次事件中被泄密的组件。这就是为什么，5月份发布的重大网络安全行政命令中提到了有关SBOM的指示。具体来说，商务部被要求来发布一个关于SBOM的最小要素基线，用来作为对所有向联邦政府售卖产品的供应商的基本要求。

　　尽管该行政令是针对于那些与联邦政府有直接合作的组织，但由于美国政府庞大的影响力，众多渴望与之合作的企业都将会受到相应的影响。毕竟，那些售卖给政府的产品，大部分也同样卖给了其他公司和组织。并且，对于许多软件开发商来说，尽管是政府推动了这个方向，他们还是希望自己的私营客户能够将SBOM视为是一种增值服务。

　　此外，联邦合同本身就是一个供应链。当行政命令推出时，前美国银行首席安全科学家，现任JupiterOne的CISO兼研究负责人，Sounil Yu向CSO表示：“众多企业都与联邦政府有着直接的合作，他们显然会受到此命令的影响。如果说这些企业受到的是直接影响，那么为它们供货的公司受到的就是间接影响。在某种程度上，这些二级影响似乎会比所谓的直接影响效果明显很多。

一个SBOM应该包括什么？

　　为了响应该行政命令，2021年7月，国家电信和信息管理局（NTIA）发布了“软件物料清单的最小元素”，概述了SBOM所需要满足联邦政府的要求。由于联邦合同在经济中的主导地位，人们预计该文件将成为整个行业的SBOM真实标准。NTIA列出了任何SBOM都应该包含的七个数据字段：

　• 供应商名称：创建、定义和标识组件的实体名称。
　• 组件名称：原供应商为软件组件指定的名称
　• 组件版本：供应商用于表明先前版本软件做出更改的标识符。
　• 其他唯一标识符：用于标识组件或用于相关数据库查找的其他标识符。例如，NIST  的CPE字典中的标识符。
　• 依赖关系：描述软件Y中包含上游组件X的关系。这对于开源项目尤为重要。
　• SBOM数据的作者：为该组件创建SBOM数据的实体名称。
　• 时间戳：记录SBOM数据程序集的日期和时间。

　　SBOMs 必须满足以下要求：

　• SBOM的格式符合SPDX, CycloneDX, 或 SWID tags这三个标准中的其中一个。这样才能确保它能够被机器识别。
　• 每个新的软件版本都必须生成一个新的SBOM，以确保它们是最新的。
　• 除了依赖关系之外，SBOM还必须解释这些关系可能存在在哪些组织所不知道的的地方。

 如何创建SBOM？

　　读到这里，你大概能够感受到SBOM那令人生畏的前景。毕竟，手动追踪软件中的所有内容无疑是一场噩梦。但幸运的是，这些担心都是多余的。大多数情况下，SBOM是由软件成分分析（SCA）工具自动生成的。SCA工具通常被置于DevSecOps管道中使用。除了生成SBOM以外，SCA工具还经常发挥着其他的增值作用。

　　SCA工具会通过扫描组织中的代码目录来寻找包，随后将它们与在线数据库进行比较，从而与已知的库相匹配。当然，还有其他的选择：例如，有一些工具可以简单地创建一个SBOM，来作为软件构建过程的一部分。

　　发布CycloneDX标准的OWASP基金会是一个极具公信力的安全组织，它发布了一个相当全面的SCA工具表单。该表单十分具有启发意义，从基本的开源命令行工具到包装精良的商业产品都有所涉及，非常全面。为了更加深入了解该产品领域，CSO提出了“7顶级软件供应链安全工具”（致力于生成SBOM的工具），并对我们的建议提供了一些相对深入的讨论。

　　在开发分布式软件时，将SBOM集成到开发实践中是非常重要的。那些没有与联邦政府签订合同（或者暂时还未签订合同）的组织，同样也需要担心供应链攻击。而SBOM则提供了一个查看第三方重用代码的黑匣子。

数世点评

　　SBOM并不是一种可以直接用于解决漏洞与威胁的最终方案，它最本质的功能在于提供一个软件开发流程的透明性，在漏洞管理与安全策略方面提供信息支持，同时帮助企业避免一系列的安全、法律以及业务问题的发生。随着SBOM得到越来越多的认可，企业也重视起SBOM利用机制的实践与流程，将其融入到安全开发生命周期的工作流程中。在实践过程中，自动化支持与格式的一致性应受到关注与满足，从而更好地实现其可用性与易用性。


参考阅读
软件成分分析及其如何识别开源软件风险
[调研]VirusTotal公开8000万勒索软件样本分析结果
[调研]大多数攻击者只需要不到十小时就能找到漏洞