大数跨境
首页
>
SBOM｜迄今为止，还不错，那又怎样？
>
0
0

SBOM｜迄今为止，还不错，那又怎样？

SBOM｜迄今为止，还不错，那又怎样？ 安势信息
2023-04-18
1
作者：Vincent Danen，Red Hat 和 Tracy Ragan，DeployHub
软件材料清单（Software Bill of Material，SBOM）已经出现了 10 多年，所以今天它比我们开始生成它们时更重要吗？根据 CISA 总监 Jen Easterly 的说法，“技术产品安全需要彻底改变”。要实现彻底的变革，IT 团队和开源社区必须打破保护软件的方法。许多新的讨论已经开始关于保护软件供应链，但是没有比 SBOM 讨论更受欢迎的了。虽然当前的讨论很大程度上涉及生成 SBOM，但我们很少讨论在拥有它们之后该做什么。
在这个基础上，ITI[1]（Information Technology Industry Council）贸易组织正式反对了拜登政府关于 SBOM（No. 14028[2]）的命令。在他们于 2022 年 11 月 21 日的信[3]中，他们认为：
“考虑到目前（不）成熟的水平，我们认为 SBOM 尚不适合作为合同要求。SBOM 的讨论需要更多时间朝着标准化的 SBOM 可以被所有软件类别扩展，并且可以被机构消耗的方向发展。”
换句话说，在政府消耗和采取 SBOM 情报之前，不要将 SBOM 作为合同的一部分要求，这与 2022 年 5 月 10 日由网络安全联盟提供的观点[4]相吻合。
我们已经讨论了创建 SBOM 十多年了，但它是否使我们更接近加强我们的软件开发实践呢？

心脏出血和 Log4J——同样的故事，不同的年份

Heartbleed（心脏出血）是 OpenSSL 加密库中的漏洞。OpenSSL 广泛用于实现传输层安全性（TLS）协议。在 2014 年，我们学到了为什么 SBOM 很重要的教训。在 Heartbleed 期间，问题是：“OpenSSL 在哪里运行，以及是哪个版本？”八年后，我们问了一个类似的问题：“Log4J 在哪里运行，以及是哪个版本？”
在 2014 年，Heartbleed 引发了更多关于 SBOM 的讨论。SPDX（Software Package Data Exchange，软件包数据交换）格式于 2011 年 8 月首次发布，因此在披露 Heartbleed 之前就存在了发现工具，但很少有 IT 组织生成 SBOM。根据 Linux 基金会的2022 年软件材料清单和网络安全报告[5]，受访的 412 家公司中有 48％表示正在生成 SBOM。这个数字需要更高。要达到这个目标，我们需要将讨论从生成 SBOM 转向消费 SBOM；否则，我们对生成 SBOM 感到高兴——迄今为止还不错，但那又怎样？只有在使用时，SBOM 才有用。

消费 SBOM 和 CVE 数据

消费 SBOM 和 CVE 数据是相似但不同的。SBOM 描述软件，包括许可证信息、起源（来自哪里）、版本信息等。将 SBOM 视为一份食材清单，但比你在杂货店找到的更详细。另一方面，CVE 数据标识特定软件中的漏洞，仅显示该软件包和版本。它包括 CVE 标识符、哪个产品或组件受到影响、严重程度评级和问题描述。这些信息相关但不同。通常，这些信息由漏洞扫描器生成，准确性不同。不是所有的扫描器都是完美的——有误报的情况吗？每个漏洞扫描器的用户都经历过误报的情况。
SBOM 数据和 CVE 数据交集的地方在于可以使用 SBOM 作为输入来关联 CVE 信息。扫描器通常必须使用各种检测方法来检测已安装的软件。然而，开源来自于多个不同的来源，许多企业供应商将修复程序回溯到他们支持的旧版本软件。例如，修复在软件 1.5 版本中的漏洞可能会被隔离并应用于企业开源供应商提供的 1.1 版本。扫描器将检测到 1.1 版本并错误地认为该软件存在漏洞。
将 SBOM 与供应商提供的漏洞数据配对，可以清楚地确定该软件包和版本已经修复。不再有误报！另一方面，真正危险的问题是假阴性。如果扫描器没有检测到漏洞存在，因为它没有检测到可能有补丁可用的软件，那么现在你就有一个未知的已知漏洞存在，没有合理的方法来减轻它。知识就是力量！
以上情况显示了消费 SBOM 数据的好处。漏洞扫描器是使用 SBOM 数据提供更准确的扫描结果的主要候选者。此外，当你依赖漏洞扫描器时，必须不断重新扫描代码以获取最准确、最新的信息。对 SBOM 进行连续扫描要容易得多。因为每个 SBOM 都与一个发布版本相关联，所以你可以立即看到新漏洞是否在你的生产环境中运行。没有猜测的余地。

生成 SBOM 数据

除了直接从你的开源供应商或上游消费 SBOM 数据外，开发人员和 IT 团队应该为他们正在构建的应用程序生成 SBOM 数据。这意味着将 SBOM 生成添加到你的开发和 DevOps 流程中。激励团队这样做的最好方法是消费数据并提供可操作的反馈。
再看漏洞扫描，它之所以受欢迎，是因为它创建可操作数据，而不像 SBOM 数据那样被隐藏在流水线的背后。大多数团队可能认为 SBOM 生成只是在合规性清单上打勾。因此，IT 团队可能认为列出 CVE 列表是最关键的步骤。毕竟，当漏洞出现时，CVE 数据很明显令人不安。
让我们以一个简单的 Java Docker 镜像为例。在镜像中，你有从构建和源代码创建的.jar 文件，以及所有运行时 jar 文件依赖项。对 Docker 镜像进行漏洞扫描，可以生成一个漏洞列表，其中包括在 Docker 镜像中找到的 jar 文件和 OS 依赖项中发现的任何 CVE。
如果你只是消费供应商或上游提供的 SBOM，你的结果将局限于容器镜像本身。虽然这是有用的，但是容器内部的软件呢？同样的限制适用——扫描工具只会报告它可以准确检测到的内容。使用容器中添加的内容扩展供应商提供的 SBOM 将产生更准确的 SBOM，从而为扫描工具提供更准确的结果。
此外，当这个应用程序在公司内部维护和开发时，就会涉及到获取应用程序中使用的依赖项的更新的问题。这就是 SBOM 生成的必要性所在。SBOM 应该提供起源信息，这样你就知道特定组件来自哪里，以及如何找到解决方案。更重要的是，SBOM 让你知道特定部署中使用了特定的软件。通过适当的使用，IT 团队将精确地知道正在使用什么，以及在哪里使用。因此，当披露漏洞时，他们知道在哪里寻找补救措施——有时在漏洞扫描器报告之前。

为什么需要 SBOM

SBOM 是提供更多关于你的组织所使用的软件的透明度的关键。知道可能存在的漏洞是至关重要的，但是需要更多的方法来加强你的软件供应链。SBOM 关注的是你的软件供应链，谁在创建你使用的软件包，你应该信任谁，以及关键的依赖关系。SBOM 提供：
  1. 软件包依赖关系的起源信息，允许团队知道在出现问题时应该联系谁，或者从哪里获得修复程序，从而提高事故响应能力。
  2. 软件包依赖项的许可证信息，这是商业软件的一个关键方面。
  3. 你的依赖项生态系统的图形化。SBOM 图形将显示你可能有多个依赖项在做同样的事情，一个软件包在整个组织中关联风险的集中，或更好地管理外部组件的采购。
  4. 在构建步骤中生成的 SBOM 将暴露用于创建你的制品（.jar、.exe、.npm 等）的所有源代码和软件包依赖项。在这个层次生成的 SBOM 显示了当在构件中发现异常时需要解决的源代码（从源代码到构件的 SBOM）。它还提供了一种精度水平，这是在构建后扫描应用程序无法获取的。
  5. SBOM 是零信任策略的基础。SBOM 规范包括显示数字签名，如果软件包已被签名。
尽管 SBOM 创建了这个关键级别的数据，但如果数据本身没有被消费，关键信息就会被隐藏在需要它的团队背后。只要 SBOM 数据没有被消费和付诸实践，SBOM 的采用将是一个持续的艰苦战斗。为什么要费力创造从未被使用过的东西呢？

总结

SBOM 提供了关键的供应链数据，但我们只是没有利用数据来推动我们的供应链决策。仅仅要求 SBOM 的生成并不是答案。SBOM 的前途，是将数据集中起来，创建组织的供应链安全配置文件，以及简单的方法来采取关键信息。利用 SBOM 数据将推动 SBOM 的采用。此外，SBOM 应该像任何制品一样被对待，并具有起源和签名。最后，SBOM 不可变性和历史跟踪将保护 SBOM 本身。

关于作者

Vincent Danen 是 Red Hat 产品安全副总裁，对计算机安全、漏洞响应、操作系统设计、安全和开发感兴趣和有经验。Vincent 在安全领域工作，特别是围绕 Linux 和操作系统安全，已有 20 多年的经验。他担任 OpenSSF 的治理委员会成员。
Tracy Ragan 是 DeployHub 的首席执行官和联合创始人。DeployHub 是一个微服务目录，将供应链安全证据转化为可操作的结果。Tracy 的职业生涯致力于软件供应链管理和流水线 DevOps 实践，特别关注于微服务和云原生架构。她曾担任 OpenSSF 治理委员会的普通成员代表。她还在 Continuous Delivery Foundation (CDF) Technology Oversite Committee 担任职务。她之前曾是 CDF 和 Eclipse 基金会的创始治理委员会成员之一。Tracy 是 Ortelius 开源项目的执行总监，这是一个目前在 Continuous Delivery Foundation 孵化的供应链证据目录。

参考资料

[1]

ITI: https://www.itic.org/

[2]

No. 14028: https://www.gsa.gov/technology/technology-products-services/it-security/executive-order-14028-improving-the-nations-cybersecurity

[3]

信: https://www.itic.org/documents/public-sector/ITILettertoOMBreM-22-18.pdf

[4]

网络安全联盟提供的观点: https://www.cybersecuritycoalition.org/reports/cybersecurity-coalition-sbom-position-paper

[5]

2022 年软件材料清单和网络安全报告: https://8112310.fs1.hubspotusercontent-na1.net/hubfs/8112310/LF%20Research/State%20of%20Software%20Bill%20of%20Materials%20-%20Report.pdf

关于安势信息


上海安势信息技术有限公司成立于2021年，致力于解决软件供应链中的安全和合规问题。作为中国领先的软件供应链安全治理工具提供商，安势信息以SCA（软件成分分析）产品作为切入点，围绕DevSecOps流程，着力于从工具到流程再到组织，坚持持续创新，打造独具特色的端到端开源治理最佳实践。


欢迎访问安势信息官www.sectrend.com.cn或发送邮件至 info@sectrend.com.cn垂询。


点击蓝字 关注我们


【声明】内容源于网络
0
0
安势信息
安势信息是国内先进的软件供应链安全治理解决方案提供商，提供包括清源SCA（软件成分分析）、清本SAST（静态代码扫描）、清正CleanBinary (二进制代码扫描)、安全服务等解决方案，提供各行业的软件供应链安全治理最佳实践。
内容 170
粉丝 0
安势信息 安势信息是国内先进的软件供应链安全治理解决方案提供商，提供包括清源SCA（软件成分分析）、清本SAST（静态代码扫描）、清正CleanBinary (二进制代码扫描)、安全服务等解决方案，提供各行业的软件供应链安全治理最佳实践。
总阅读453
粉丝0
内容170