随着越来越多地使用第三方组件和冗长的软件供应链，攻击者现在可以通过一次攻击同时破坏许多软件包。为了应对这种新的攻击媒介，更多的开发和 DevOps 团队以及安全专业人员正在寻求纳入软件物料清单 (SBOM)。
软件供应链包括用于制作应用程序的所有内容，从工程师编写的独特代码到他们使用的开发工具，以及代码库中的任何第三方组件（专有和开源）。虽然开发人员对自己的代码负责， 一个SBOM 跟踪确保每个第三方组件安全所需的信息。这包括：
- 它的来源地
- 具体使用的版本
- 任何已知的漏洞和补丁状态
- 在应用程序中使用的地点和时间
- 许可信息
以及任何其他相关的安全信息。
通过了解最终产品中的每一行代码，组织可以展示安全的开发实践并向客户提供保证。
随着 SBOM 的使用范围显着扩大，IT 研究和咨询公司 Gartner 最近发布了“SBOM 的创新洞察”，”一份报告描述了这个概念、它的好处、使用的各种标准以及对实施 SBOM 的组织的建议。
由于许多人无法访问 Gartner 的完整报告，因此我们将介绍一些关键发现以及我们自己对组织成功使用 SBOM 需要考虑的因素的看法。但首先，让我们讨论一下目前的状况 软件供应链攻击.
软件供应链风险不断上升
尽管软件包试图在竞争中脱颖而出并专注于使它们与众不同的地方，但在基本功能方面总会有一些重叠。例如，每个组织都需要加密用户数据，并且大多数组织需要考虑跨多个设备同步。
虽然开发人员可能花费大量时间和精力编写代码来执行这些通用功能，但合并已在使用的现成组件要容易得多。无论是购买的还是开源的，第三方代码都简化了开发过程并显着缩短了上市时间。
然而，它也带来了漏洞。如今，软件的安全程度取决于供应链中最薄弱的环节。攻击者利用这一事实，以越来越快的速度瞄准软件供应链中常用或过时的组件。
最近的一个报道 216 年 2015 月至 2019 年 929 月期间，仅发现 2019 起软件供应链攻击。2020 年 12,000 月至 2021 年 650 月期间，这一数字大幅跃升至 XNUMX 起，随后在 XNUMX 年激增，超过 XNUMX 起软件供应链攻击，同比增长增加XNUMX%。
来源: 黑暗阅读
一个2021 福雷斯特调查 530 名网络安全决策者发现，现在 33% 的外部攻击来自第三方服务或软件漏洞。
鉴于最近攻击的加速，美国政府做出这样的决定也就不足为奇了 软件供应链安全 一个新的优先事项。这包括发布 安全软件开发框架 (SDF) 和2022年XNUMX月 管理和预算局备忘录 制定 2024 财年的网络投资优先事项，这两项投资重点都充分关注减轻供应链风险。
随着攻击数量激增、新闻中的著名例子（例如 SolarWinds、Log4J 等）以及美国政府拉响警报，组织需要提高其软件供应链的可见性，并为每个项目维护全面的软件物料清单。他们的产品。
SBOM 来救援！提高软件供应链的可见性、信任度和安全性
需求是发明之母，像供应链攻击这样严重的威胁当然需要解决方案。值得庆幸的是，SBOM 的发明意味着我们现在有了反击的工具，确保只有安全且可信的组件才能进入代码库。
SBOM 基于制造或建筑中常见的物理物料清单 (BOM)。例如，汽车制造商利用 BOM 来盘点每辆车中使用的每个组件，无论该组件是由 OEM 还是第三方制造的。如果某个特定零件出现问题，制造商可以通过 BOM 识别每辆受影响的车辆并通知车主。
SBOM 相当于软件行业。充当每个产品中存在的每个软件组件的清单。如果发现某个组件存在漏洞，组织可以快速确定受影响的用户，并制定计划来通知和减轻风险。
由于复杂的软件堆栈包含大量开源和其他第三方组件，因此跟踪产品面临的每项风险可能具有挑战性。 SBOM 允许开发、DevOps 和安全团队甚至客户了解此风险，快速查看新发现的漏洞是否会影响他们。
SBOM 还有助于：
- 防止许可证中毒——当开源组件开放您的知识产权时，就会将您的产品暴露给所有人查看。
- 识别遗留代码中的风险 - 分解现有代码库以识别每个第三方库、开源存储库、开发工具等，以确定潜在的过时组件或存在的任何其他风险。
SBOM 具有诸多优势，因此得到了广泛采用。然而，最近的一则 报告 研究发现，虽然 76% 的组织已做好一定程度的 SBOM“准备”，但到 47 年，只有 2021% 的组织积极使用 SBOM。预计到 2022 年，这一数字将上升到四分之三以上的组织 (78%)，而近 90% 的组织将在 XNUMX 年积极使用 SBOM。下一年。
来源: VentureBeat的
Gartner 的 SBOM 创新洞察报告 — 高级摘要
Gartner 2022 年 SBOM 创新洞察报告提供了有关软件物料清单的重要性和实施的重要信息：
“软件物料清单提高了软件供应链中专有和开源代码的可见性、透明度、安全性和完整性。为了实现这些优势，软件工程领导者应该在整个软件交付生命周期中集成 SBOM。”
组织经常努力维护专有和开源依赖项的可见性，从而产生大量的 软件供应链安全风险 以及潜在的合规问题。这是因为他们缺乏足够的工具或未能实施安全开发实践和标准。
借助 SBOM，开发人员可以发现并编译软件包中每段第三方代码的安全详细信息。软件供应链攻击的兴起表明，将开源或商业代码视为密封、安全的“黑匣子”是失败的。
如果不知道“盒子”里面有什么，您永远无法真正了解您的软件所面临的风险。因此，最好的解决方案是仔细跟踪您用来检查已知漏洞的每个“盒子”。
Gartner 建议每个组织：
- 为他们生产的每个软件包生成 SBOM
- 验证所有使用的软件（开源或商业）的 SBOM
- 持续重新评估 SBOM 数据以了解新的安全风险（部署之前和之后）
鉴于软件供应链环境日益受到威胁，Gartner 预测，为关键基础设施构建或购买软件的组织中有 60% 将强制执行 SBOM。到 20 年，这一数字将是当前数字 (2022%) 的三倍。
“SBOM 是安全与合规工具箱中的重要工具。它们帮助持续验证软件完整性并提醒利益相关者注意安全漏洞和政策违规行为。”
这一切对你有何影响？
那么，这一切对您和您的组织意味着什么？ Gartner 建议组织：
- 利用 SBOM 跟踪整个软件供应链的依赖关系，同时考虑软件开发生命周期中的每个组件
- 使用工具自动生成 SBOM，系统地扫描和验证您的产品
- 快速响应软件供应链中发现的任何受影响的组件
- 使用每个新软件工件更新 SBOM，即在构建过程中而不是仅在项目开始时创建 SBOM
- 仅重用具有经过验证且安全的 SBOM 的模块
- 根据广泛支持的格式（例如软件包数据交换 (SPDX)、软件识别 (SWID) 或 CycloneDX）实施基于标准的 SBOM 流程
- 确保与您合作的任何商业软件提供商也通过基于标准的方法使用 SBOM
- 与利益相关者共享 SBOM 和来源数据，使他们了解受影响的组件和风险相关数据
SBOM 是现代软件安全的关键工具。但为了改善整个行业的状况，需要在组织内外都可以访问它们。以 SBOM 形式共享漏洞数据还可以增加利益相关者的信心和信任，让他们知道他们使用的软件中不存在已知漏洞。
Scribe Security 提供具有共享功能的托管 SBOM 管理平台。帮助组织保证容器完整性并为其生产的软件提供可操作的见解。注册抢先体验即可免费开始 抄写平台.
Scribe Security 对 Gartner 报告的看法——透明度和证据是关键
At 抄写员安全，我们相信 SBOM 是保护建立在不断扩大的供应链之上的现代软件包的关键。 SBOM 全面记录开发流程，以保证整个供应链的端到端可见性。由于跨团队和组织共享功能，我们的平台将 SBOM 的可见性与透明度结合在一起。
Scribe 提供了一个中心，软件生产者和消费者可以聚集在一起共享各种软件包或组件的可信度证明。我们利用加密技术来收集数字签名，跟踪开发过程中的变化。这些签名确保了保证软件供应链的有效性和安全性的证据基础。
即使是目前可能不考虑生成 SBOM 的小型企业也可以从了解该流程中受益。即使您在生产中拥有稳定的版本，Scribe 也可以提供连续扫描，因此您可以检查新漏洞并确定整个软件开发生命周期的趋势。
总结
随着软件供应链攻击的惊人增长，组织需要考虑新的方法来保证他们构建的软件产品和他们使用的软件产品的安全。
第一步是生成软件物料清单，详细说明软件包代码库中存在的所有组件。了解正在运行的内容使组织能够领先于漏洞并共享应用程序构建的完整性。
Gartner 最近关于 SBOM 的报告很好地总结了这种情况：
“SBOM 帮助组织确定他们是否容易受到先前在软件组件中发现的安全漏洞的影响。这些组件可以是内部开发的、商业采购的或开源软件库。 SBOM 生成并验证有关代码来源和组件之间关系的信息，这有助于软件工程团队在开发（例如代码注入）和部署（例如二进制篡改）过程中检测恶意攻击。”
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
