Transformers and GPTs weren’t the only buzzwords in the software industry in 2021. Disruptions from the SolarWinds attack in 2020 led the US government to issue an executive order (EO 14028) urging companies to improve the nation's cybersecurity. With much focus on supply chain security, the “Software Bill of Materials” became a requirement.
This article will explore what an SBOM is and how much it contributes to improving supply chain security.
What is an SBOM?
A Software Bill of Materials (SBOM) is a collection of ingredients that make up the software. In simple words, it is an inventory of dependencies. The term became famous due to rising software supply chain security concerns.
As the industry aligned behind application security standards, attackers witnessed an easier path by breaking into unmaintained dependencies. The attacker economics also made sense because breaking into one package meant gaining access to any system using that package.
Earlier this year, we saw xzutils [CVE-2024-3094] alter the behavior of OpenSSH. A sock-puppet attack compromised one of the packages in that dependency chain, compromising high-value software.
An SBOM aims to highlight all the dependencies used in a particular package. This allows monitoring of system vulnerabilities and exposures.
Fig 1. Direct/Indirect dependencies captured in SBOMs
Benefits of SBOMs
Before SBOM, many organizations struggled getting visibility into their exposure. In 2021, when the log4j vulnerability surfaced, most companies scrambled to figure out whether they were affected. SBOMs could help by improving the transparency and visibility of dependencies.
SPDX is one of the standard SBOM formats, and a complete version includes the following information:
- Inventory of all components and dependencies, including their version number, source code repository, and other available metadata.
- List of software licenses of each component and their available vulnerability information.
- An overall summary of the software, describing its dependency relationships, including upstream and downstream users.
A sample specification will resemble:
As a software consumer, it’s recommended to use all SBOMs in your organization to inventory software dependencies and track their security in a central place. CISOs around the world adopted this strategy, leading to the wide popularity of SBOMs.
SBOMs definitely solve some observability issues, but how does it help with software supply chain security?
Limitations of SBOMs
Being able to inject malicious code into some component of software that leads to unintended behavior is exploiting the supply chain. While SBOMs may help with improved visibility, they have severe limitations. First, SBOMs are self-produced. Software builders have complete control over what goes into the SBOM. Similar to some vulnerability databases, incompleteness in SBOMs can lead to a false sense of security. Second, tracking vulnerabilities of each dependency in SBOMs for your organization can quickly result in thousands of new vulnerabilities daily. SBOMs do not provide any information on exploitability of a vulnerability.
Not all dependencies are equal, but SBOMs treat them the same way. To improve the security posture of dependencies, you need to establish secure development practices. NIST SP 800-218, the Secure Software Development Framework, provides more actionable standards for improving supply chain security in general.
Supply Chain goes beyond Dependencies
A compromised build system equally contributes to the security of software. Let’s break down phases of building a software in the following diagram.
Fig 2. Partial picture of Supply Chain Security entry points
Packages included in the final SBOM of a product are a subset of supply chain artifacts used in building it. An attacker who can compromise any part of the chain can inject malware into the final output. It’s important to ensure that you secure all parts of the chain. SBOMs can help lift security health from the status quo, but frameworks like Supply-chain Levels for Software Artifacts (SLSA) and Secure Software Development Framework (SSDF) must be used to improve security as you’re building new packages.
It’s important to remember that while SBOMs might be sufficient for compliance requirements, without proper utilization, they will only contribute to your already overflowing vulnerability dashboard.