共计 2540 个字符，预计需要花费 7 分钟才能阅读完成。
软件蕴含大量且范畴宽泛的组件、局部和相互依赖关系。须要无效缓解与应用软件相干的平安危险；须要恪守与组件相干的许可证。通过第三方代码（包含开源软件 (OSS)）理解产品中所有我的项目的出处至关重要，无论这些元素源自企业的团队还是团队之外。确保安全的最佳办法是保护软件中所有组件的以后“成分列表”列表——软件资料清单 (SBOM)。
什么是 SBOM？
就像食品的成分列表一样，SBOM 就是软件中组件和服务的列表。SBOM 相似于制作和产品开发中的供应链文档。在产品开发供应链中，制造商应用特定供应商的整机，装置组件来构建产品，而后跟踪产品从制造商到购买它的零售店的旅行历史。与此相似，网络环境中的服务器机器是应用交付给制造厂的供应商部件构建的。服务器构建实现，而后从一个地位挪动到另一个地位，直到它达到装置它的数据中心。这个过程中的每一步都是供应链的一部分。
SBOM 是进步整个软件平安供应链透明度和问责制的重要一步，但这只是在软件市场实现有意义的平安透明度的第一步。除了成分之外，软件消费者还应该分明地理解为软件构想的威逼模型、现有的平安机制、执行的平安测试以及开发人员是否承受过培训。
在之前的文章 OpenSSF 平安打算：SBOM 将驱动软件供应链平安 有提到，目前美国联邦政府采取了积极主动的措施，要求政府机构生产和生产的所有软件都应用 SBOM。《对于改善国家网络安全的行政命令》指出，网络攻击的频率和复杂性的减少催化了公共和公有部门联手爱护软件供应链的场面。这也标记着 SBOM 驱动的将来曾经到来。
SBOM 的劣势
SBOM 是平安团队的现实工具，他们须要深刻理解第三方软件危险以理解他们所应用的版本、任何许可影响以及可能减少平安债权的其余依赖项。最初，SBOM 帮忙事件响应团队辨认破绽的起源以及是否被利用，以便疾速告诉客户。随着开源库的激增和 log4j 等宽泛应用的库的大规模开发，SBOM 能够帮忙组织在其应用程序组合中管制开源。以下是 SBOM 的劣势：
- SBOM 能够帮忙组织优先思考危险最高的开源应用。第一个指标是杜绝应用具备已知破绽的库，并随时关注每个开源库的最新版本。
- SBOM 在危机状况下也十分有用。当库中的新破绽被披露时，组织必须可能疾速精确地追踪该版本在其企业中的应用地位，这一点至关重要。应用来自企业各团队的 SBOM 数据并继续更新是疾速响应的要害。
最初，通过将 SBOM 信息提供给软件消费者，这样无效解决了软件市场中的信息不对称问题。能够拜访无关应用程序安全性的残缺信息（包含 SBOM 中的库信息）的消费者能够做出理智的决定，同时也激励开发者创立平安可信赖的杰出软件。
SBOM 的作用
SBOM 是一种正式且可查问的记录，其中蕴含用于构建软件的各种组件的详细信息和关系，包含开源软件和所有引入的第三方软件。SBOM 提供的清单是平安软件开发框架（secure software development framework）的要害因素，有助于在软件开发过程中检测破绽，而后在软件生命周期中施展继续作用。
软件部件从各种不受监管的起源引入应用程序：供应商代码、合作伙伴代码、开源我的项目和外部开发。开发人员常常应用来自各种中央的代码（开源和第三方代码），这些代码不像商业软件那样具备雷同的入站管制和审查。开源和第三方代码来自出名生态系统（如 Apache Software Foundation 和 Eclipse Foundation）和权威工件存储库，包含 Maven Central (Java)、NuGet (.NET)、npm (JS)、PyPI (Python)、RubyGems (Ruby) 等等。有时，代码还能够通过寰球各地的集体开发人员进入企业，这些开发人员将他们的代码托管在源代码存储库上，例如 GitHub 或 GitLab。
可能拜访此代码中反映的翻新和常识通常对用户无益，但也提出了一个须要解决的重要问题：代码中蕴含什么？这就是 SBOM 的亮点，借助 SBOM，软件公司能够辨认：
- 软件中的组件 / 成分
- 这些组件来自哪里
- 每个组件的许可证信息
- 软件（及其运行的设施）的安全漏洞状态
- 哪些局部须要评估和补救（以及您在此过程中的地位）
- 向客户和合作伙伴交付的合规性工件
美国国家电信和信息管理局 (NTIA) 概述了 SBOM 的最低因素，例如数据字段（名称、许可证和版本）。目前已存在多种 SBOM 的格局，例如 CycloneDX、OpenChain 和 SPDX，行业也正在致力标准化 SBOM 的格局。SBOM 以多种格局创立和保护，有时在比拟或编译 SBOM 时会遇到挑战。
优化 SBOM
随着 SBOM 成为支流，无效应用 SBOM 的要害之一是全面理解多个信息源。基于 SaaS 的 SBOM 提供了一种对立的库存治理办法，从不同起源获取和聚合数据，可能分明地理解平安问题以及与许可证和不合规部件相干的法律危险。
具备基于云的库存治理的优化 SBOM 将成为商业智能的继续起源，提供可操作的视图，反对针对特定关注畛域的监控和警报。通过从宽泛的起源（外部和 / 或合作伙伴、供应商和供应商）获取数据以辨认和记录所有第三方知识产权 (IP)，对立和协调来自多个起源和各种格局的外部和内部 SBOM 从整个组织到一个繁多的、规范化的视图。由此产生的对于组件或许可证应用以及平安和破绽裸露的见解意味着，如果许可证在不合规或发现破绽时存在问题，企业能够采取相应措施来解决问题。
这种 SBOM 办法还提供了弱小的合规性工件，企业能够将这些工件提供给其客户和上游供应链合作伙伴。这不仅可能强调企业软件的安全性，而且这种对产品的透明度也有助于增强业务关系。
作为软件成分剖析 (SCA) 程序的一部分，基于云的集中式 SBOM 治理使企业可能做的不仅仅是辨认软件中应用的成分，还能促成继续的策略管理、风险管理打算和许可证合规打算。有了这些信息，企业就能够更好地进行资源管理，理解在哪里以及如何将员工资源用于开发和 / 或当新报告的安全漏洞被辨认为应用程序的一个组成部分时所需的补救措施。
总结
通过 SBOM，无论是企业自主开发的代码还是组织内部引入的软件组件，企业将领有对立的数据来辨认危险。同时企业将取得必要的信息来帮忙及时解决问题，而被动辨认软件许可证和平安危险有助于确保一种受损成分不会毁坏企业软件，或危及企业在软件供应链中的角色。
