One of the more significant aspects of a new document on software supply chain security from the Enduring Security Framework (ESF) is the recommendation of binary analysis and reproducible builds as best practices.
The document, titled "Securing the Software Supply Chain: Recommended Practices for Managing Open-Source Software and Software Bill of Materials," builds on previous efforts by the U.S. federal government to foster formal standards for bolstering software security against current and emergent threats, including the most recent push for Secure by Design, which seeks to shift liability for software compromises to software teams.
Developed by the ESF, a public-private working group led by the National Security Agency and the Cybersecurity and Infrastructure Security Agency, the new guidelines focus heavily on practices for ensuring the security of open-source components in enterprise software. But within the document, the ESF goes a step further, calling for application security tools that go beyond legacy testing by using complex binary analysis, as well as employing reproducible builds.
Here's what software producers and consumers need to know about the recommendations in the new guidelines.
[ See ReversingGlass: Why binary analysis matters | Learn more: The Power of Complex Binary Analysis ]
A significant call to action on supply chain security
The ESF document recommends that developers and third-party software suppliers perform binary analysis as a final package verification step:
"Before shipping the software package to customers, the developer or supplier should perform binary composition analysis to verify the contents of the package and reproducible build validation when possible."
Such binary analysis tools can determine what is included in the final deliverables "and identify potential issues in the final packages, [including] a range of activities from the detection of potential vulnerabilities and threats to including Software of Unknown Provenance (SOUP) and secrets inadvertently included in the final packages."
Significantly, the ESF document recommended that binary code analysis practices be applied not just to software vendors, but also to the phases of software acquisition, deployment, and operations.
In addition, the ESF recommends that software developers use reproducible builds, when possible, to ensure that code in a package has not been tampered with or modified.
To mitigate risk, go beyond legacy AppSec
Security experts consider both binary analysis and reproducible builds crucial components of supply chain security. The goal with binary code analysis is to inspect the binaries in a finished software package for potential security issues to validate configuration and code provenance and look for hidden functionality and undocumented features such as backdoors.
Binary analysis enables visibility into code that runs in production and can be especially useful when an organization does not have access to a particular software package's source code, as is almost aways the case when purchasing commercial products.
Meanwhile, a reproducible build is an additional step to ensure the software that an organization develops or acquires from a developer or commercial supplier behaves the same when run in parallel, which can expose things such as tampering or malware that has entered the package through the software supply chain.
Binary analysis bolsters SBOMs
John Gallagher, vice president at enterprise security platform Viako, said the inclusion of these practices is a significant step forward in software supply chain security. Binary analysis and reproducible builds can enable more trust in using software bills of materials (SBOMs), he said.
Binary analysis adds to current source code analysis methods by providing detailed information on dependencies and security risks, both of which are critically important.
"Generating an SBOM based on binary code analysis can catch transitive dependencies that can lead to security and privacy issues compared to generating an SBOM through source code analysis. The implicit 'trust' for an SBOM is the ability to use it for catching vulnerabilities, and a combination of source code analysis and binary code analysis will provide a more 'trusted' SBOM."
—John Gallagher
Recommending binary analysis will also likely advance the use of the Vulnerability Exploitability eXchange (VEX) for managing and tracking application and firmware vulnerabilities, Gallagher said. VEX is an intermediate representation of binary code that is architecture-agnostic, and when used with platforms such as angr, can make program analysis easier, he said. "In other words, VEX offers a level of abstraction for easier binary analysis."
Enter the new era of software supply chain security
Matt Rose, field CISO at ReversingLabs, said the inclusion of binary code analysis as a recommended best practice reflects a broader and ongoing formalization of the definition of software supply chain security that's been happening over the last couple of years.
Following the Biden administration's May 2021 Executive Order on Improving the Nation’s Cybersecurity, which specifically called out the need to enhance security of software supply chains, there has been an evolving understanding of what exactly that entails, Rose said.
Increasingly, there is recognition of the need for organizations to have mechanisms to assess the security of commercial third-party software they consume that go beyond SBOMs, which are little more than a list of ingredients in software. SBOMs don't give organizations visibility into the security posture of the package itself, Rose said.
Binary code analysis can help organizations evaluate and verify the security of not just internally developed software, but also third-party commercial software in their environment, before it is released.
"It is the final examination of a package for software supply chain risk, which allows for trust in that piece of software that you are either developing for your customers or that you are buying to help operate your business."
—Matt Rose
Saša Zdjelar, Chief Trust Officer at ReversingLabs, said the recommended use of binary analysis and reproducible builds marked a significant step forward in ensuring better software supply chain security. AppSec practices such as SAST and DAST typically only apply to a small subset of internally developed systems and applications at many organizations, he said.
Legacy application security testing is out of sync with modern software development because it does not cover software developed by commercial providers and other third parties.
"Our ability to analyze binaries is key to understanding risk in third party software."
—Saša Zdjelar
Modern supply chain security needs accountability
A lot of the success of software supply chain security programs depends on where the accountability for implementing the recommended practices rests, Zdjelar said.
Putting the onus on software suppliers alone to do such testing, for example, is unlikely to bolster trust, Zdjelar said. The ESF document recommends that the developer or supplier should perform binary analysis before releasing the package. But it's unclear how much confidence consumers will have in the results of vendor-performed analysis.
Until the software industry gets to that space, binary analysis needs to be part of the software acquisition process as well. And companies seeking to manage software risk need tools that can verify all software being developed or run across their organizations.
"When you buy your car, do you feel the need to do your own crash testing, or do you believe the crashworthiness, the seatbelts, and airbags and crumple zones all work as intended? Generally, we all believe they work as intended because the automobile industry has over time earned our trust in that space."
—Saša Zdjelar
