是时候加入SBOM了

DevOps、IT安全和IT治理社区将记住2021年软件材料清单(简称SBOM)从“拥有它很好”变成了“必须拥有”。

多年来，SBOM已经成为一个关键DevSecOps每个人都必须彻底理解并融入他们的软件开发生命周期．简而言之，soms提供了关于哪些组件组成了一个软件，以及它们是如何组合在一起的可见性，因此很容易确定它是否包含安全性和遵从性问题。

在这篇博文中，您将了解什么是SBOM，它将如何使您受益，围绕它存在哪些误解，以及为什么它必须是SDLC安全和遵从性的关键元素。

SBOM是如何从舞台的两翼转移到舞台中央的

SBOM标准由美国食品和药物管理局(FDA)于2018年提出，以确保医疗设备软件具有与食品相同的问责水平，因为它直接影响个人健康。但是SBOM的崛起与最近发生的两件事直接相关:毁灭性的太阳风将于2020年底登陆以及白宫2021年5月起的网络安全行政命令。

太阳风漏洞被突出供应链攻击在这种方法中，恶意软件隐藏在合法软件中，然后通过授权渠道分发给毫无戒心的最终用户。在IT监控供应商SolarWinds的案例中，黑客以间接传递依赖的形式将恶意软件注入到其Orion平台的软件构建过程中。

几个月来，SolarWinds无意中发布了带有该漏洞的产品更新，该漏洞旨在帮助黑客通过后门入侵客户的Orion服务器。大约1.8万名客户收到了被破坏的更新，几十名客户被入侵，包括著名跨国公司而且美国联邦政府机构．

当时，这是最新的一连串的供应链黑客攻击，但它的范围和后果使它与众不同，引发了对软件开发安全和DevSecOps的严格审查和越来越多的关注。随着其灾难性的后果还能感觉到，它是这是白宫引用的担任美国总统乔·拜登的司机改善国家网络安全的行政命令．

顺序突出显示SBOM的重要性作为“包含构建软件中使用的各种组件的细节和供应链关系的正式记录”。白宫将soms比作食品配料清单，宣称它们对软件制造商、软件买家和软件运营商都很有用。

SBOM为应用程序的软件组件之间的所有依赖关系提供了透明度，这有助于防止或更快地减轻供应链黑客行为。“了解软件的供应链，获取SBOM，并使用它来分析已知的漏洞，对管理风险至关重要，”命令写道。

尽管美国政府将为软件制造商提供更具体的安全要求，但它已经在命令中声明，它将要求它所购买的每一个软件都附带详细的SBOM。

soms:可见性和透明度

开源软件的安全性不容忽视，了解您向客户出售的软件、从供应商购买的软件或从Internet上免费下载的软件中有哪些内容是至关重要的。

一项又一项的研究表明，开源软件占据了平均应用程序代码库的大部分，通常高达90%以上，包括那些存在严重漏洞或其创建者多年未更新的风险组件。

换句话说，未经检查的软件本质上是不安全的或有缺陷的。

因此，为您开发的软件拥有soms已经成为DevSecOps的核心最佳实践，以及越来越常见的监管要求(特别是在高度监管的行业，如金融和医疗保健)，以及与越来越多的公共和私营部门客户进行业务的条件，这一点并不令人惊讶。

通过为您营销和使用的软件组件提供透明度和可见性，soms帮助您的组织保护其员工、客户和声誉，同时减少补救成本和法律责任和政府罚款的风险。

尽管向美国政府出售软件需要SBOM信息，但受监管的行业以及世界各地的政府组织也可能要求这些信息。因此，记录和报告您构建的软件的SBOM应该成为一种通用的必要实践。

SBOM里有什么?

SBOM包含组成一个软件的“成分”的列表，包括库和模块——无论它们是开源的还是专有的，免费的还是付费的——以及关于开发工具的信息，以及在构建过程中使用的CI(持续集成)环境变量。

SBOM还可以概述软件是什么时候构建的，它经历了哪些SDLC阶段——开发、QA、分期、生产——以及已经检测和修复了哪些安全和遵从性问题。

这些信息促进了DevSecOps的工作，并帮助在各种用例中维护安全和遵从性，包括:

• 对于软件生产者:SBOM通过详细描述所有正在使用的上游组件，以及跟踪应用程序不同版本之间的变化，帮助他们构建和维护应用程序。当一个影响其应用程序的漏洞被披露时，软件供应商可以立即检测到哪些版本受到影响以及如何受到影响，并迅速修复问题并通知客户。

• 软件买家;SBOM帮助他们了解所购买产品的组成，以确保它符合他们的安全和合规标准和要求，特别是如果他们处于高度监管的行业。它还帮助他们预测和量化特定软件包中的固有风险。

• 对于软件运营商:SBOM有助于告知他们的流程，包括漏洞和资产管理、许可遵从性验证和风险软件组件的识别。SBOM还可以帮助他们优化软件的性能和可靠性，降低停机和故障的风险。

应用程序越复杂，SBOM就越有价值，因为它提供了组件内和软件的多个容器层(包括应用程序层、运行时层和基本操作系统层)之间的所有相互依赖关系的清晰度。

例如，就像一个大而复杂的蛋糕一样，一个复杂的web服务具有包含许多成分的多层。在web服务的情况下，这些层通常是Docker映像，每一层都应该有自己的SBOM。还应该有一个主要的、涵盖所有单独的SBOM。

通过这种方式，您可以跟踪所有依赖项和子依赖项，并隔离web服务的各个组件，以查明受安全性或遵从性问题影响的组件，例如关键漏洞或错误配置。有了这些信息，您就可以及早、快速地检测和补救问题，减少被破坏的机会。例如，据估计，几乎75%的带有脆弱库的应用程序可以通过移动到带有更新库的新版本来修复。

SBOM误解

多年来，出现了对sbom毫无根据的反对意见，包括:

• SBOM不会为黑客提供路线图吗?不，SBOM中的信息不会给攻击者提供入侵您的软件所需的线索，他们甚至不会费心查看SBOM。他们有更强大和复杂的工具来执行他们的邪恶行为。

• 难道你不需要在SBOM中公开你的源代码吗?不，你不需要。SBOM包含关于您的软件中有什么以及创建它的环境的信息，但不包含您的源代码。

• 一个SBOM不会暴露我的机密知识产权吗?不，soms不包含私有IP数据。

重要的是要理解SBOM只是关于软件的元数据，而不是软件本身。它包含了制作软件所用材料的数据，但没有关于组装过程的数据。

JFrog和AWS如何提供帮助

与JFrog DevOps平台-特别是与JFrog Artifactory, JFrog Xray和JFrog分布- - - - - -托管在AWS上，您可以很容易地获得SBOM所需的所有粒度数据，包括:

• 所有软件的传递依赖项
• 详细的CI环境信息
• 安全和遵从性数据，包括应用程序中所有构建中的漏洞和不遵从性许可的“爆炸半径”
• 分发数据，例如如何、何时以及在哪里部署软件，哪些客户收到了它，等等

这个关于您的软件的信息宝库可以通过JFrog UI和JFrog REST API，以便您可以将其导出到您选择的第三方工具。

(关于JFrog DevOps平台如何帮助您确定是否受到SolarWinds漏洞的影响，在哪里受到影响，以及如何修复受影响的库的技术细节，请阅读我们最近的博客文章"自动评估和补救太阳风攻击"）

总而言之，现在是时候把更多的注意力放在SBOM上，并把它移到您的DevSecOps优先级列表上了，原因如上所述。

如果你想进一步讨论这个话题，请毫不犹豫地联系我们。