SBOM（软件构建物料清单）还不足够：开发人员需要通过使用二进制源验证的过程深入了解软件的构建方式。
美国黑帽 – 拉斯维加斯 – 8月9日星期三，开源OWASP的依赖检查项目的创始人和负责人提出了一种解决软件供应链安全问题的方法，使用了一种名为二进制源验证的新颖过程。
长期从事软件开发的ServiceNow首席工程师和OWASP专家Jeremy Long解释了二进制源验证的概念，它涉及在比软件的源代码更深层次的位置检查软件，以查看在编码过程中创建的构建工件，并验证其合法性。他指出，仅提供源代码视图的软件构建物料清单（SBOM）并不足以作为安全措施。
二进制验证思想的核心源自1984年肯·汤普森的一篇著名论文《反思对可信赖的信任》，他是Unix的共同作者。该论文概述了一种通过在代码编译器中设置后门的方式来破坏信任，使得后门在发布的源代码中不可见。然而，如果开发人员使用被破坏的编译器创建下一个版本的软件，它会将后门注入到该编译器中。随后，如果开发人员使用该编译器编译操作系统，后门也会被注入到操作系统中。汤普森在论文中透露，正是通过这种方式，他自己将后门深深地植入了Unix系统中。
“（后门）从来不在源代码中，它只存在于编译器的二进制输出中，” Long解释道。因此，开发人员工具可以验证源代码中的运行时依赖关系，对于开发人员发现后门或任何恶意代码在整个软件构建过程中都没有帮助，他说道。
他表示：“我们没有深入思考我们构建软件的方式。”
Long将在今天的Black Hat USA 2023会议上，举办名为“反思软件供应链中的信任”的会议，详细阐述他的解决方案以及与软件供应链安全相关的核心问题。
软件供应链攻击的潜在解决方案
在他的研究中，Long主要关注一些高级编程语言，如Java和.NET，以演示二进制源代码验证的方法。他目前看到的与他设想的解决方案最接近的是IBM的Code Genome项目，该项目也是基于Thompson的论文，并旨在为软件提供“具有语义意义的指纹”，根据该项目的网站描述。
他指出，二进制源代码验证为开发人员提供了一种独立验证构件的方法。以Java编写的软件在开发过程中生成的JAR文件就是一个例子。他强调，这种验证不仅仅是检查代码是否产生了所谓的“可重现构建”，而是提供了一种软件验证的方式。
Long解释道：“这是一种真正提高您对构建未被篡改的保证的方式。您可以查看二进制文件中的指令集，并验证这些指令集是否能够由源代码生成。”
SBOM 不足以保证软件构建安全
虽然SBOM被认为可以让组织更加清楚地了解软件中包含了什么，但Long解释说，这还不够。
SBOMs是软件附带的组件和运行时依赖的清单，可以帮助确保在部署之前软件不包含已知的漏洞。然而，仅仅处理已知漏洞使得SBOMs成为解决供应链安全的不完整方式。
一项旨在解决这个问题的初步工作是所谓的配方物料清单。配方物料清单已被添加到名为CycloneDX的开源SBOM工具的新版本中，Long解释道。它不仅提供了软件运行所需的依赖关系的可见性，还提供了有关软件构建的详细信息，包括构建平台、插件、库和其他组件。这样，如果其中任何一个组件存在已知的漏洞，可以在部署之前进行识别。
Long表示：“配方物料清单绝对是朝着正确方向迈出的一步。”然而，他指出，它仍然主要提供事后取证的数据，组织可以使用这些数据来查找是否已部署了存在漏洞的软件，而不能确保软件是从头开始构建的，没有恶意代码。
Long表示：“它仍然无法处理零日漏洞类型的问题。”他说：“目前没有人有这样的工具。”
Long认为，二进制源验证是解决软件供应链面临的安全问题的潜在方式，尽管他承认这需要时间才能实现。
这项研究发生在一个戏剧性的背景下：在过去几年中，发生了一系列高影响力的软件供应链攻击，其中包括SolarWinds和Log4j。这些攻击表明攻击者已经成功地破解了如何利用软件依赖关系来针对软件发动能够影响数百万系统的攻击。这个问题被证明是很难解决的，因为开发人员在部署各种系统之前，没有简单的方法来识别应用程序组件中存在的恶意代码。此外，即使在发现漏洞之后，追踪已经在使用中的软件中的易受攻击组件也是一项极为困难的任务，正如Log4j案例所展示的那样。
攻击者越来越多地利用这些复杂性，并将他们的攻击方式提升到了在软件开发之前就攻击软件的级别。对开源代码库和其他开发人员用于编写应用程序的编程平台和工具（如最近备受瞩目的Python）的攻击变得越来越普遍。这样做给恶意行为者提供了一种间接但有效的渠道，可以一次性攻击软件供应链中的多个系统。
本文转载自https://www.darkreading.com/application-security/owasp-lead-gaping-hole-software-supply-chain-security，本文观点不代表墨知立场。