Source: www.darkreading.com – Author: Elizabeth Montalbano, Contributor, Dark Reading
BLACK HAT USA – Las Vegas – Wednesday, Aug. 9 The founder and lead of the open-source OWASP‘s dependency-check project has devised what he thinks is a solution to the problem of securing the software supply chain, using a novel process called binary source validation.
The idea of binary source validation involves inspecting software at a layer deeper than the software’s source code, to look at the build artifacts created while coding, and validate them as legitimate, explains long-time software developer Jeremy Long, principal engineer at ServiceNow and an OSWAP guru. He notes that software bills of material (SBOMs) that provide a view into source code simply aren’t sufficient security measures.
The kernel of the binary validation idea lies in a well-known 1984 paper entitled “Reflections on Trusting Trust” by Ken Thompson, the co-author of Unix, which outlined the process of compromising a code compiler with a backdoor in such a way that the backdoor does not appear in the published source code. Yet, if a developer uses the compromised compiler to create next version of the software, it injects the backdoor into that compiler. Subsequently, if a developer compiles the OS with the compiler, the backdoor also gets injected into the OS. This scenario is how Thompson himself dropped a backdoor deep into Unix, he revealed in his paper.
“[The backdoor] is never in the source code, it’s only in the binary output of the compiler,” Long explains. Because of this, developer tools that can validate runtime dependencies in source code won’t be of any help to developers to spot the backdoor — or any malicious code, for that matter — in their overall software build, he says.
“We are not looking deeply enough at how we are building software,” he says.
Long will outline his solution and other issues at the heart of why the software supply chain is so difficult to secure in a session today called “Reflections on Trust in the Software Supply Chain,” at the Black Hat USA 2023 conference in Las Vegas.
A Potential Solution to Software Supply Chain Attacks
In his research, Long focused on some of the higher-level programming languages, such as Java and .NET, for a demonstration of binary source validation. The closest solution that he’s seen so far to the one he’s envisioned is IBM’s Code Genome project, which also springs from Thompson’s paper and aims to provide a “semantically meaningful fingerprint” for software, according to the website for the project.
Binary source validation provides a way for developers to validate the artifact — for instance, the JAR file produced when developing software written in Java — independently rather than merely checking to see if the code produces what’s called a “reproduceable build” as a way of software verification, he says.
“It’s a way to really increase your assurance that your build has not been compromised,” Long explains. “You can look at the instruction set in the binary and validate whether or not that could be produced by the source code.”
SBOMs Aren’t Enough for Software Build Security
SBOMs are often touted as giving organizations more visibility into what goes into their software, but Long explains that it’s not enough.
SBOMs are an inventory of the components and runtime dependencies that ship with a piece of software, which can help ensure it does not include a known vulnerability before being deployed. But the fact that they deal only with known vulnerabilities makes SBOMs an incomplete way to tackle supply chain security.
A nascent effort to tackle this issue is what’s called a formulation bill of materials, or FBOM. FBOM — which has been added into a new version of an open source SBOM tool called CycloneDX — provides visibility into not only the dependencies that software requires to run, but also the details on how the software was built in terms of build platform, plug-ins, libraries, and other components, Long explains. That way, if any of these items has known vulnerabilities, they can be identified before deployment.
“FBOM is absolutely a step in the right direction,” Long says. However, it still provides largely forensic data post-breach that organizations can use to find out if they’ve deployed a vulnerable piece of software, not ensure the software is built from the ground up without malicious code, he notes.
“It still doesn’t deal with zero-day type issues,” Long says. “Nobody has the tooling [for this].”
Long sees binary source validation as a potential way to help solve the security issues that the software supply-chain faces, though it will take time to come to fruition, he acknowledges.
The research comes against a dramatic backdrop: A spate of high-impact software supply chain attacks over the last few years — among them SolarWinds and Log4j — demonstrate that attackers have cracked the code, literally, on how to target software to successfully mount attacks that can reach millions of systems through software dependencies. This issue has proven difficult to combat, as there is no easy way for developers to identify malicious code that’s present in a component of an application before it’s deployed across myriad systems. Moreover, tracking down vulnerable components in software that’s already in use — even after flaws are identified — also is an extremely difficult task, as seen with Log4j.
Attackers increasingly are exploiting these complexities, and have taken their approach to a level that attacks software before it’s even developed. Attacks on open source code libraries and other programming platforms and tools that developers use to write applications — such as Python, a popular target of late — are becoming more commonplace. Doing this gives malicious actors an indirect yet effective channel to attack multiple systems across the software supply chain in one fell swoop.
Original Post URL: https://www.darkreading.com/application-security/owasp-lead-gaping-hole-software-supply-chain-security
Category & Tags: –
