代码漏洞的数量和影响都在不断增长。随着越来越多的软件成分来自不同的供应商即软件供应链，快速找到并修复其中的漏洞也变得越发艰难。最近，某软件团队发现了一个 IP 漏洞且不得不通过 LinkedIn 找到能够修复该漏洞的财富100强公司，使它们意识到这个问题的存在。

其中的一个解决之道是使用软件物料清单 (SBOM)。美国商务部国家电信和信息管理局 (NTIA) 的网络安全计划主管 Allan Friedman 分享了通过 SBOM 使代码内部运作机制透明化的重要性。

SBOM 是什么？

SBOM 是描述软件包依赖树的一系列元数据，包括多种关键信息如提供商、版本号和组件名称。这些基本详情在分析软件漏洞时发挥着关键作用。这些漏洞根植于多种组件中，如下流程图所示。

SBOM 的价值是什么？

透明度使市场繁荣发展。例如，食品原料和标记使人们获得做出明智决策的所需知识。虽然标签无法保证人们将健康饮食，但有助于获得做出正确饮食选择的信息。同样，一份 SBOM 无法自动解决所有的安全问题，但使得团队更快更容易地解决这些问题。

SBOM 同时能够说明软件组件的很多信息。例如，如果SBOM中存在6个数据包版本，则很有可能其中的一个版本易受攻击。

这些能力远不止于漏洞，还表现在冗余方面。例如，有多少开源项目仅依赖于一个组件的问题，它被称为“尤克里里问题“，或者说，项目所有人可能会放弃这个爱好，拿起尤克里里，搁浅所有的依赖项目。

为何 SBOM 尚未成为标准实践？

SBOM 尚未成为当前的标准实践，原因很多。虽然它们正在站稳脚跟，但仍然存在一个鸡蛋和鸡的问题，没有人在询问这一点，因此也就没有提供。

另外，在供应链中并不一定易于创建 SBOM。作为一个新概念，这个行业挣扎于与其相关的最佳实践和工具集。例如，SBOM 要求命名一致，而供应商甚至合作伙伴会给相同组件不同的命名。

另外还有许可证和开源问题。

如何构建 SBOM？

按照NTIA的流程，具有一些制定 SBOM 的指导原则。其中最重要的原则就是意识到在学会走之前必须先会爬。我们有必要制定一个基础的 SBOM，便于团队进行对齐。所创建的 SBOM 需要是机器可读的，以便自动化，之后需要发布到一个已知或可发现的位置，便于访问和分析。

如何实现 SBOM？

当前实现 SBOM 的格式有三种：

1、SPDIX：Linux 基金会的根本投入。该计划是沟通SBOM信息的开放标准，包括组件、许可证、版权和安全引用。

2、CycloneDX：专为安全上下文和供应链组件分析而构建。

3、 SWID 标记：由记录关于软件组件唯一信息且协助存储管理计划的文件组成。

SBOM 示例

医疗行业可以见到重要的 SBOM 概念验证情况，它依赖于物料清单来找到漏洞和可利用组件。这样做还可使供应商了解重要医疗设备的软件问题。

工具集

虽然现在已有制作 SBOM 的工具且未来也会不断出现，但 NTIA 给出了工具集分类，帮助团队选择正确的工具集。

这份分类围绕的是 SBOM：

• 生产：在选择 SBOM 的格式和输出工件，以及分析并编辑已有列表时需要谨慎仔细。

• 耗尽：良好的工具集使得团队能够读取内容并且对比不同的 SBOM 从而检测出其中的不同之处。

• 变革：可结合SBOM 和其它数据的多个来源进行审计。

NTIA 还鼓励工具间的互操作性，以便所有人一起提高意识并提升工具的用处。

政府认可

就像医疗设备所达到的那样（生死问题），SBOM 应该也能未其它行业和应用程序做到这一点。当前的管理层意识到了网络安全的重要性并发布行政令，说明了 SBOM 及其价值。

SBOM 的未来

不止在美国，在全球也是一样，政府和行业认为 SBOM 对于安全的作用越来越重要。我们正在见证 SBOM 被认可和发挥作用的未来。

未来的愿景是，越来越多的组织机构在采用 SBOM 方法并帮助社区优化工具，以满足行业内的更多需求。SBOM 并非所有安全问题的解决方案，而是团队做出智慧安全决策的一部分。

原文链接

https://blog.sonatype.com/sbom-from-the-idea-of-transparency-to-the-reality-of-code

声明：本文来自代码卫士，版权归作者所有。文章内容仅代表作者独立观点，不代表士冗科技立场，转载目的在于传递更多信息。如有侵权，请联系 service@expshell.com。