共计 4724 个字符，预计需要花费 12 分钟才能阅读完成。
在上一篇文章中，咱们为大家介绍了 SBOM 最根底元素波及的数据字段、自动化反对与最佳实际和流程。在本篇文章中，咱们会为大家介绍 SBOM 最根底元素领导意见的最初一个局部内容，在理解上述最根底元素之后, SBOM 应该具备哪些信息和特点来适应更宽泛的利用场景，并为大家介绍本领导意见对 SBOM 今后倒退的瞻望。
文章关键词：SBOM；SBOM 最根底元素；数据字段；破绽
举荐的数据字段
除了之前咱们介绍的必要数据字段之外，本领导意见也举荐有能力的厂商通过增加以下数据字段的形式来更好地治理开源组件的应用。
基于云的软件和 SaaS 类软件
许多古代的软件应用程序都是作为一种服务提供的。这给生成 SBOM 数据带来了特地的挑战。因为软件不是在客户的基础设施上运行，也不在客户的管制之下，所以风险管理的角色也不同。用户不负责保护，也不能管制任何环境因素。理解破绽或危险信息并采取行动的责任在于服务的提供商。此外，古代网络应用程序往往有更快的公布和更新周期，使得间接提供 SBOM 数据变得不太事实。
同时，在云计算的大背景下，捕获软件供应链的危险也有很大挑战。服务提供商不仅要跟踪他们负责生产的软件供应链中的元数据，还要跟踪反对应用程序的基础设施栈中的元数据，不论是在提供商的间接管制下还是来自某个内部服务提供商。许多应用程序还利用第三方服务，通过 API 向其余组织发送数据和申请。
捕捉对于整个利用栈和第三方服务的有意义的元数据是咱们正在进行的一些工作，但还没有标准化或足够成熟，无奈跨组织施行。
NIST 对 “EO- 要害软件 “ 的定义实用于基于云的软件，但 NIST 倡议最后的施行阶段应侧重于 “ 外部软件 ”。
倡议：在短期内，倡议云服务提供商有一个外部的 SBOM。该 SBOM 必须放弃与上述最根底因素大致相同的性能，只管格局和架构可能因提供商的外部零碎而异。云服务提供商还必须有能力针对这些信息采取及时的口头。咱们置信，随着工夫的推移，SBOM 数据将会被整合到第三方风险管理和供应链风险管理工具和流程中的最佳实际中。
SBOM 的完整性和真实性
SBOM 的使用者会十分关注 SBOM 数据的起源的可验证性，确认它没有被扭转。在软件畛域，完整性和真实性最常通过签名和公钥来实现。随着 SBOM 的施行，会有一些现有的软件和元数据的完整性和真实性的措施能够被利用。
下面形容的一些 SBOM 数据格式能够明确地反对这些安全措施的采纳，一些开源畛域正在进行的工作正在优先解决来自开发环境的元数据的签名问题。这种机制应容许对某一软件的每个组件进行签名，并容许用户确定签名是否非法。完整性和真实性是许多政府机构的首要任务，特地是在国家平安畛域。
破绽与 SBOM
针对代码平安，SBOM 最次要的用例是辨认软件供应链中的已知破绽和危险。一些开发者可能会抉择在 SBOM 中存储破绽数据，并且几种 SBOM 数据格式都反对这种做法。
这种办法对开发者有显著的价值。然而，咱们要晓得 SBOM 数据次要是动态的。也就是说，它反映了某个工夫点上的特定软件的属性。同时，破绽数据是动静的，并随着工夫的推移而一直变动。以前不被认为有破绽的软件，随着新破绽的发现，可能会“变得”有破绽。除非有十分具体的条件和程序，否则不能认为 SBOM 中的破绽数据是残缺和最新的。SBOM 的数据很可能最终肯定要与破绽数据源相联。(然而这并不会限度向软件使用者提供破绽、软件缺陷和危险信息的价值）。
倡议：将破绽数据放在与 SBOM 不同的数据结构中进行追踪。随着这两类数据的倒退和技术的成熟，经营层面应着重于两类数据之间的映射和分割。如果破绽数据是跨组织共享的，那么破绽数据和 SBOM 都能够应用相似的模型进行散发、访问控制和应用。
依赖关系中的脆弱性和可利用性
该领导意见认为，软件供应链中有一些破绽并不会使组织和机构面临危险，在 SBOM 中关注那些被认为不会对上游软件产生影响的上游有破绽的组件，将浪费时间和资源，而且不能提供间接的平安利益。
倡议
1、SBOM 提供者必须做出一些可靠性判断，即一个破绽是否不影响特定的软件。这其中起因有很多：编译器可能从组件中删除受影响的代码，破绽可能在执行门路中无奈达到，内联爱护的存在，或者其余一系列的起因。现在，产品安全事件响应小组（product security incident response teams, PSIRTs）应该能够做出这些判断，由他们跟踪外部的依赖和危险。
2、向此 SBOM 数据的上游用户做沟通，保障该破绽不会使组织处于危险之中。这会把一个软件（无关的破绽）和该破绽的状态分割起来。社区将此称为“破绽可利用性数据交换”，或 VEX（Vulnerability Exploitability eXchange）。VEX 的外围是替换某个软件是否受到某个破绽的“影响”。在这种状况下，如果认为没有必要采取行动，那么状态就是“未受影响”。目前，VEX 正在作为通用平安征询框架（Common Security Advisory Framework）中的一个配置文件来施行，它可能提供关于软件是否受破绽影响的机器可读信息，并能链接到具体的 SBOM 数据中。其余实现形式也是可行的。倡议 SBOM 数据分析工具应具备主动纳入 VEX 数据的能力。
零碎遗留软件和二进制剖析
从效率和效用的角度来看，SBOM 数据应该由供应商提供。然而，有时候这并不理论，也不是最好的抉择。在某些状况下，甚至可能无奈取得源代码，只有指标代码（object code）可用于生成 SBOM。实际上，这些没有被保护的软件可被利用的危险最大。老旧的软件面临着更大的不被保护的危险。遗留软件的代码库较老，而且常常被用于要害基础设施的重要局部，往往使透明度变得更加重要，特地是对于评估已知破绽的危险。
从源码库中生成 SBOM，或者在构建软件的时候生成 SBOM，或者从曾经构建好的软件中生成 SBOM，这些形式具备显著的区别。尽管有许多非凡状况，但要求 SBOM 数据的人应尽量从构建过程中获取，因为构建的实例捕捉了软件构建的细节，包含反映编译器或其余工具的变动。
倡议：二进制剖析工具能够用来更好地理解无关零碎中的组件和依赖关系。二进制剖析也可用于验证 SBOM 内容，或帮忙理解 SBOM 数据中的空白。
施行中的灵活性与统一性
在许多涵盖各种软件的平安畛域，在灵活性和统一性的需要之间存在着根本的矛盾。这并不是 SBOM 所独有的。软件生态系统微小的范畴和规模导致了一系列非凡的思考。这不仅包含软件用处之间的区别（例如：传统企业软件、嵌入式零碎、容器化软件），还包含不同语言和工具的独特性能。同时，显然也须要一些交融和对立。任何组织机构都会因为解决各种不兼容的 SBOM 而产生微小的破费。要想取得上述 SBOM 用例的种种长处，须要一些可预测性和统一性。
在整个生态系统中胜利施行 SBOM，既须要宽泛的规定和政策，也须要明确哪些畛域是能够有灵活性存在的。这些畛域的抉择应思考社区和机构的反馈意见。具体畛域包含遗留技术和更高保障要求的软件，在这些畛域，沉闷和继续的平安威逼可能须要更具体的供应链信息和更严格的要求。
倡议：所有建设在最根底因素的要求应借鉴两个要害概念。首先，所有的平安，特地是 SBOM，是一个漫长的过程，而不是一个繁多的指标。第二，SBOM 的根本准则是进步软件供应链的透明度
将来瞻望
鉴于 SBOM 是一种新兴的技术和实际，因而还有大量的工作要做，该领导意见给出了对于将来 SBOM 的新亮点的瞻望。SBOM 不会解决所有的平安或供应链攻打。比方最近在供应链上产生的几起很重大的攻打，其指标不是软件组件，而是用于治理软件开发和构建过程的工具和零碎。针对这些威逼的相干的进攻措施曾经受到了器重并被部署到生态系统中。除了最根底元素中所规定的三个方面外，本领导意见对于如下几个方面做了瞻望。
- 企业和组织要尽可能多的捕捉整个软件生命周期的细节，并有加密做保障，以防被篡改。
- 融入自动化的工具和流程很重要，同时也须要具备消化这些自动化流程的能力。
- 进步 SBOM 的机器可读性，这其中波及了业余的语义解读能力和数据的标准化和规范化。
- EO 14028 中要求了其余与平安开发和软件供应链相干的平安步骤，这些步骤可能与软件开发无关，但最佳的形式是独自记录，并与 SBOMs 相关联。
- 因为古代利用开发和云原生架构的独特性质，对于动静的依赖关系、第三方服务的调用和其余没有间接蕴含在软件构建中的依赖关系都须要纳入 SBOM 的领域之中，确保不会因为误操作而引入破绽。
- SBOM 肯定会不断创新，模块化构造能够最好地反对多样化的翻新和适应性。
- SBOM 不应独立于软件畛域，也应与硬件数据分割起来。同时，硬件供应链的危险也具备本身的挑战，应思考硬件特定的元数据，并与 SBOM 数据一起整合到整个供应链风险管理中。
该领导意见也列举了一些 SBOM 倒退过程中所遇到的难题，比方：
- 不同生态系统之间软件身份与 SBOM 的散发。应用繁多的命名空间看似能够解决这个问题，然而过于理想化，因为其中波及扩展性、多样性等诸多阻碍。
- 版本治理办法和零碎的多样性问题亟待解决。这须要进一步的协调工作。
- SBOM 数据的中心化。这种形式的长处是：当 SBOMs 集中存储在一个能够被其余应用程序和零碎轻松查问的存储库中时，会取得更大的价值，比方能够用来取得对组织、甚至生态系统或国家层面所面临的零碎危险的更多信息。它能够通过让协调者理解哪些组织或供应商有潜在危险，从而促成破绽披露。也能够理解哪些组件应用最宽泛，或在最要害的部门，并优先思考平安钻研或加固办法。然而，有些人放心这些要害信息会被利用进行新的攻打。咱们有必要进一步钻研如何共享、爱护和应用 SBOM 数据。
近期呈现了一些针对更无效实现 SBOM 数据的发现、拜访和主动获取的技术：
- 制造商描述符（Manufacturer Usage Descriptor）：一种容许设施在网络上替换本身的重要信息，包含网络性能，特地是本文件中的 SBOMs 的机制。
- 数字资料清单（Digital Bill of Materials）：是一种提供包含 SBOM 在内的开放式供应链数据的多种证实，以及围绕这些证实的共享和拜访策略无关执行的解决方案。
- OpenC2：是一种标准化语言，用于提供或反对网络进攻的技术的指挥和管制；现阶段，OpenC2 曾经被利用来解决、加工 SBOM 数据并据此采取行动。
SBOM 要达成的指标还远远没有实现，须要通过一直地翻新与迭代来欠缺，是一个长期的重复的过程。这就须要跨组织的摸索来证实其可行性和可扩展性，最终由各部门和规范专家将技术和实际编入国际标准。本报告应被看作是一个终点，而不是最初的论断。
以上是咱们深度解读《SBOM 的最根底元素》的完结篇，如果您对咱们的解读有任何倡议或想法，欢送交换探讨。
对于安势信息
上海安势信息技术有限公司致力于解决软件供应链中的平安和合规问题。作为中国市场当先的软件供应链平安治理工具提供商，安势信息以 SCA（软件组成剖析）产品作为切入点，围绕 DevSecOps 流程，着力于从工具到流程再到组织，保持继续翻新，打造独具特色的端到端开源治理最佳实际。
清源 (CleanSource) SCA，是安势信息研发的一款领有齐全自主知识产权的软件成分剖析工具，可能帮忙企业升高和治理其利用或容器中因应用开源软件和其余第三方代码（软件）引入的平安、品质与许可证合规性危险。目前安势信息已与国内多家高科技头部企业建设了深厚的单干关系。欢送拜访安势信息官网 http://www.sectrend.com.cn 或发送邮件至 info@sectrend.com.cn 垂询。
文章未经受权请勿转载。如有转载需要，请当时分割：marketing@sectrend.com.cn
