如何更好地构建与利用SBOM
软件物料清单（SBOMs）的有效性在于它能否帮助企业在合规方面发挥作用，解释整个代码库，并实现企业规模上的互操作性。然而，目前行业中缺乏一种统一的规范来实现这些目标。
简单地生成一个SBOM相对容易。但要生成符合规范标准、允许企业大规模互操作的SBOM往往困难重重。这就是"fullMonty SBOM"的意义所在，它描述了一个全面的SBOM解决方案，为其未来的实用工具提供了安全、法律以及操作用途等方面所需的内容和互操作性。要想实现有效的安全性或操作假设，这种全面性的SBOM往往是不可或缺的。
美国总统拜登于2021年5月发布的行政命令14028中强调了联邦政府需要购买包含SBOM的软件的要求。同时该命令也强调了“了解软件供应链，获取并利用SBOM来分析已知漏洞，在风险管理中至关重要。”这对于安全领域来说是一个重要的推动因素。它引发了用户对所用软件的内部运作方式的更多疑问。人们开始对常用软件的内部结构和工作原理提出更多问题，以确保其安全性和可靠性，特别是在涉及政府以及与政府相关的业务时。
如今市场上越来越多的安全厂商开始主动生成SBOM作为其产品的一部分。尽管每个工具在具体功能上有所不同，但这无疑是该领域的一项重大进步，为用户提供了对现代云基础架构中复杂代码部署的可见性。
在该领域中，许多安全厂商和一些开源框架都可以扫描依赖关系树。然而，目前主要问题就是SBOM的生成缺乏统一的标准。如果能够成功实施统一标准，那么SBOM就可以顺利应用于风险管理和漏洞影响评估等环节。但如果数据无法在多个平台上进行标准化，那么构建全面的风险模型将会变得困难。
一个有效的SBOM文件需要满足以下三项要求：
格式符合标准规范
为了实现SBOM的广泛交换以及自动读取功能，它们的交换格式必须符合标准规范。
目前业界认可度最高的两个标准为SPDX和CycloneDX。这些标准旨在确保SBOM输出的一致性。也就是说，当使用不同的SBOM生成工具来生成同一软件的SBOM时，它们会产生相同的结果。这些统一的格式可以根据不同的使用案例和行业垂直领域来进行定制，企业可以选择“包含”、“排除”或“链接到”特定的信息（例如许可证、版权和漏洞等）。这样的灵活性可以在满足不同需求的同时，促进标准化的应用和交流。
需要注意的是，SPDX和CycloneDX仅描述了SBOM文件结构的标准，而没有涉及到SBOM文件的全面性和准确性等方面。生成SBOM文件的过程或工具只是按照标准来对所输入文件中的信息进行组织和呈现，而无法保证输入文件本身的质量或准确性。也就是说，如果使用的SBOM生成过程或工具接受了错误或不完整的输入文件，那么即使它能够按照规定的结构生成SBOM文件，但所产生的SBOM文件仍然可能是错误或不完整的。
全面性
对于几乎所有的应用软件来说，开源组件都是其攻击面的最大构成部分。这些开源组件出自世界各地的开发者之手，平均占据软件应用的76%。Log4j就是一个典型的例子，它向人们展现了单个开源组件中的单个漏洞所能够在全球范围内产生的巨大影响。对于大多数组织来说，要想确保软件供应链以及信息基础设施的安全性，就必须要把对开源软件漏洞的迅速识别及修复列入优先级最高的安全事项行列。
其实，很多人都对SBOM有一种偏见，认为它只是一个开源软件（ open source software， OSS)）的物料清单。但实际上，大多数软件成分分析（software composition analysis ，SCA）供应商所生成的不同类型SBOM中，除了会列出OSS组件，同时还会将不同级别的传递依赖关系展现出来。对于那些仅包含OSS的SBOM，它可能会使组织忽略掉软件供应链中其他类型代码所携带的漏洞。
一个全面的SBOM会对应用程序中的所有组成部分进行揭示，包括自定义代码、开源组件以及第三方的非开源组件。这是因为并非只有开源代码会存在漏洞，其他不同类型的代码中也同样具有携载漏洞的可能，这一点至关重要。
互操作性
SBOM本质上是一种静态文档。但如果从软件供应商那里获取的SBOM文件只能帮助组织进行软件成分的检查，那么其价值就显得十分有限。SBOM的真正价值在于对其的利用，即互操作性。组织要能够将其纳入诸如补丁管理以及部署风险评估等其他生命周期风险管理的流程之中，同时还要能够在企业规模上对其进行操作。
安全团队可以通过具有互操作性的SBOM进行的三个常见的操作，即合并、查询和监控。
• 合并:一个完整的汽车所包含的配件往往出自不同的供应商，不同的软件供应商通常会使用不同的标准格式来生成各自的SBOM，而汽车制造商则需要将这些不同格式的SBOM聚合到一个系统级的SBOM之中。
• 查询: 如果某个被广泛应用的组件中存在新的零日漏洞，那么就需要查询所有的SBOM来确定组织中的众多软件应用中哪些包含了这个具体的易受攻击的组件。假设组织具有数千个应用需要检查，那么平均每天就要处理大约60个新CVE，这在技术上是很难实现的。因此，对于互操作性以及有效的软件风险管理来说，能够通过单一的界面来对数千个SBOM进行查询检测是十分关键的要素。
• 监控: 安全团队可以将旨在实现互操作性的SBOM与威胁情报和漏洞管理系统进行集成。这样，当出现新的零日漏洞时，它们就可以对所有现存的SBOM进行自动检测，以查找该漏洞的波及范围，同向其产品生命周期管理系统通知风险。
从软件物料清单（SBOM）中，我们可以了解到以下三个关键内容：
了解软件的应用范围
通常情况下，安全专业人员需要时刻搞清楚“组织拥有哪些软件？以及这些软件应用于何处？”如果将软件依赖项纳入到开发与生产级别的代码中，那么这个问题将变得更加复杂。然而实际上，一些组织拥有多个产品或者多个具有不同风险配置文件的环境，这样一来，为了做出合理的商业决策，需要处理的问题就更多了。因此，除了软件物料清单（SBOM）之外，组织还需要更多的元数据和环境信息。所以说，了解软件及其所应用的位置将有助于建立上下文，以便正确地进行风险决策。
了解使用的开源库所面临的法律风险
组织需要充分了解开源许可软件，以确保其行为符合组织政策，这是经常被忽视的方面。许可证问题可能会引发法律纠纷，使组织面临罚款的风险。组织可以通过研究过去的案例来了解这些风险。此外，额外的上下文数据和审查日期有助于确保合规性的基础建设。另外还需要注意的是，工程使用案例往往会随着时间的推移而变化。
了解下游库
还记得那个名为“faker”的开源项目事件吗？它几乎彻底摧毁了整个下游的用户。大部分组织在扫描过程中时常会忽略一些依赖项，而依赖关系却往往存在在这些被忽视的依赖项中。需要注意的是，要递归地搜索组织中的代码（尤其是在生产环境中），从而发现可能受影响的下游库。
提前准备备选方案
检测到开源库中的漏洞之后，紧接着要做的就是进行漏洞修复。修复漏洞需要花费时间，短则几天，多则数月。要想有效地采取应对措施，关键就是要及时地意识到自己的风险状态。为了应对漏洞与风险，组织可能需要自行删除库中的代码，或者将所涉及到的开源项目复制到独立的代码库中，并在其内部进行维护和开发。当然，完全消除所有风险概率是不现实的，组织能做到是要提前制定针对该弱点的计划，以在风险发生时，尽量减轻可能遭遇的冲击与损失。
SBOM实践还有很长一段路要走。人们正在努力将其格式标准化为机器可读的标准，例如SPDX、CycloneDX等，这些标准远远超出了本文所提及的内容。如今，行业正朝着正确的方向前进。但与此同时，我们还需要努力将这些标准统一到一个共同的机器可读格式中，从而避免不同标准的爆炸性增长。
随着组织不断构建规模更大、结构更为复杂的模块化软件，引入的外部依赖性也开始飞速增长，最终扩大了供应链攻击的风险。尽管我们可以采取手动的模式来进行开发，但不可否认的，未来的方向是实现整个工作流程（从发现漏洞到修复）的自动化。
最后，同样需要明确的是，SBOM并非万能的解决方案。全面的SBOM固然重要，但它也只是软件供应链风险管理中的一小部分。确保自研代码和开源软件中（OSS）不存在漏洞，软件符合法规要求，以及开发流程安全防篡改同样是其中重要的环节。类比于食物供应链，人们肯定不愿食用成分未知或者由卫生不达标的工厂生产的食物。同理，企业也需要确保其软件供应链的安全性，才能赢得用户等利益相关者的信任和支持。
无论是食物还是软件，都必须要确保产品是安全可消费的，而这仅依靠SBOM是远远不够的。在整个产品的制作过程中，其他类型的安全性流程以及定期的检测同样重要。
