Two years after the requirement for Software Bills of Materials (SBOMs) were announced, we are nowhere near achieving them. Are SBOMs an achievable dream, or an elusive fantasy?
President Biden’s cybersecurity executive order of May 2021 introduced the concept of the mandatory software bill of materials (SBOM). The intention can be summarized quite simply – to provide transparency and visibility into the components used within new software, and thereby improve the security of the software supply chain.
Eighteen months later, in December 2022, a big tech lobbying group representing Amazon, Apple, Cisco, Google, IBM, Intel, Mastercard, Meta, Microsoft, Samsung, Siemens, Verisign and more, wrote to the OMB: “We ask that OMB discourage agencies from requiring artifacts [SBOMs} until there is a greater understanding of how they ought to be provided and until agencies are ready to consume the artifacts that they request.”
If after eighteen months – and we’re still in the same position today – meaningful use of SBOMs is unachievable, we need to ask what needs to be done to fulfill Biden’s executive order.
The function of the SBOM
The purpose of the SBOM is to improve the security of the software supply chain by providing visibility into areas of an application that are otherwise hidden. It provides details on every code component that is used in an application. “It builds out a list of all the packages and shared libraries used in each application, along with their version number,” explains Matt Psencik, director at Tanium.
“If a vulnerability is released for a specific package, you can either update that package, remove it, or contact a vendor to see if a new patch is available to remediate the vulnerability,” he continues.
The SBOM is designed to provide details on every code component included in the application, whether commercial software components, open source software (OSS) libraries and dependencies, or any in-house developed libraries. “This information can be used to prioritize security patches and updates, track and manage vulnerabilities, and monitor compliance with relevant regulations and standards,” says Anthony Tam, manager of security engineering at Tigera.
The usual analogy is with a list of ingredients on a food product. Knowing the ingredients allows the purchaser to detect any risks involved in consuming the product. But the SBOM goes much deeper and provides significantly more data than a food ingredients list.
While it details every component from whatever source, the primary target and biggest problem in the software supply chain is OSS. OSS is also the biggest problem and hindrance for the SBOM project.
The OSS problem
OSS is pervasive. It is unlikely that any new application is built without using OSS components. They are free and readily available, and they help developers build their new applications faster.
The problem is there is so much OSS, it is often developed by a single person or small team of collaborators (generally unpaid), and each OSS library is often further dependent on the use of other libraries or components that have their own further dependencies. It is uneconomical in a free market’s need for speed economy to expect application developers to know what dependencies are pulled into their own application or even which parts of an OSS library are used or unused by their application.
Consider these figures. According to GitHub’s Octoverse 2022 report, there were 52 million new open source projects on GitHub in 2022, with developers across GitHub making more than 413 million contributions to open source projects throughout the year. Sourceforge hosts a further 500,000 OSS projects, while Apache hosts another 350 projects. And there are other sources.
The developers of these projects tend to be coders, not security specialists. In theory, the open nature of the code allows third party researchers to examine the code for bugs, vulnerabilities, and malware. Unfortunately, the same openness allows attackers to find those vulnerabilities and sometimes insert their own malware.
The SBOM is designed to make OSS problems more visible to commercial software application developers, and application buyers and users. But the sheer scale of the OSS market explains the difficulties. It is a major reason for the slow progress of the SBOM project.
Current state of the SBOM
One of the perceived problems in the evolution of the SBOM is there is no precise specification of what it should provide, or in what format, nor how it should be interpreted and used. Perhaps the closest is the NTIA’s Minimum Elements for a Software Bill of Materials published in July 2021. But as this document (PDF) concludes, “The minimum elements of an SBOM are a starting point… the Federal Government should encourage or develop resources on how to implement SBOMs.”
CISA is the focal point for the SBOM project. It describes its role as “facilitating community engagement, development, and progress, with a focus on scaling and operationalization, as well as tools, new technologies, and new use cases.”
In April 2023, CISA released three SBOM-related documents. The first was titled the Sharing Lifecycle Report. It shows how an SBOM moves from the author to the consumer, and how the SBOM can lead to product enrichment in the process.
But the document doesn’t specify how the SBOM should be created, how it should be shared, nor how it should be interpreted.
Two further documents published in April are Types of Software Bill of Material (SBOM) Documents, and Minimum Requirements for Vulnerability Exploitability eXchange (VEX). The ‘Types’ document lists six different SBOM types together with their benefits and limitations. It concludes, “These definitions are meant as a starting point…”
The ‘VEX’ document (the VEX concept was introduced in the NTIA minimum requirements document) says “This document specifies the minimum elements to create a VEX document. These elements are derived from, but may not fully conform to, existing VEX documentation and implementations, as noted in section 4.1. This document also specifies some optional VEX elements.”
Throughout these documents there are options the software author can use in the production and consumption of SBOMs, but nothing to say what the author should or must be doing. It is this lack of instruction, this allowance of market forces to phrase and solve the problem, that is perhaps the biggest current drag on the SBOM project.
Different security vendors are developing different products to help automate the process – firstly to be able to generate SBOMs, and secondly to be able to receive, process, and remediate any issues found and/or highlighted by the SBOM. Automation will be essential for this project, but haphazard automation will not solve the problem.
Pete Morgan, co-founder and CSO at Phylum, explains the issue. “I have a little test lab setup at home where I have six or seven tools that can take a piece of code and generate an SBOM from it. And then I have five or six other tools that will take in the output, and try to interpret it and do something with it. I run these tests against the same codebase – and each tool produces a different SBOM; and none of them are interpretable by the other tools.”
The VEX
The VEX document, while not strictly part of the SBOM itself, is an important part of the SBOM project. The SBOM will help purchasers know about any vulnerabilities that exist in the software they use. But the vulnerabilities must be known, and through the VEX provided by the software developer (or elsewhere), they must be informed.
Ground level in the process is the OSS developer – and this is a problem. Technically, the OSS developer must inform users of the code on any vulnerabilities discovered within the code. Morgan describes the problem: “These developers at the foundation of almost all software products do not have advanced product security teams. The idea that they will give us accurate vulnerability information about their own code is a bit too hopeful. It would be like asking a blind lookout to tell us if someone is coming.”
Nevertheless, the VEX (and several other extensions that are being discussed), are “interesting ideas that we don’t have the process, or understanding of process, to use effectively today.”
Stephen Robinson, senior threat intelligence analyst at WithSecure, believes that the ability to maintain SBOM and VEX documentation will be key. “Keeping an SBOM up to date and propagating those updates to consumers is a key issue,” he says. “The security landscape changes constantly as CVEs are identified and patches are issued – and so SBOMs will change too.”
The National Cybersecurity Strategy
Both the value and problems with the SBOM project are rooted in the amorphous mass that is known as OSS. It Is simply unreasonable to expect sole developers and small groups of collaborators to be able to produce timely and accurate SBOM documentation.
Strategic Objective 3.3 of the National Cybersecurity Strategy, published on March 1, 2023, talks about shifting security responsibility from the user to the software developer. But in more detail, it says, “Responsibility must be placed on the stakeholders most capable of taking action to prevent bad outcomes, not on the end-users that often bear the consequences of insecure software nor on the open source developer of a component…” (our emphasis).
The effect of this will be to focus responsibility for SBOMs and VEX documents on the vendor firm producing commercial software rather than the developer of open source software libraries. The problem is there is no specific guidance nor instruction on how this might be achieved. Without this guidance, the SME or startup firm rushing to get new products to market could easily miss vulnerabilities lurking within the sub-dependencies of the OSS libraries they use.
“SBOMs are only worth it to an organization if they actively listen to intelligence sources about package vulnerabilities to search for and actually remediate if a vulnerable package is found,” comments Psencik. “Most SBOMs today are a tool that gives you much deeper information than you previously had; but if that information is not actioned it will be just another item in a security team’s tool chest gathering dust.”
What needs to be done?
While we have discussed the slow progress of the SBOM project and the mountainous issues that need to be solved, it would be hard to find a cybersecurity specialist who doesn’t believe in the project. The common opinion is that it is an important development for the security of the software supply chain, and once it is implemented, it will benefit everyone.
“More usage and standardization will improve the current state of SBOMs,” comments Bud Broomhead, CEO at Viakoo, “especially with respect to giving organizations proven and automated ways of using SBOMs to improve security.”
The primary problems may be more political than organizational. As per the Cybersecurity Strategy document, the current administration will seek to ‘shape market forces’ and ‘will use Federal purchasing power and grant making’ to achieve this. What it cannot do is impose a federal requirement across all cybersecurity vendors.
This then becomes a question of whether the federal government can realistically shape market forces. “I actually don’t think this will ever be achieved if we just let the markets do what they want. I do think regulation is required for this,” warns Morgan. But the administration can only regulate the purchasing of federal agencies. Smaller software developers with no intention of selling into the federal market, could simply ignore such regulation.
He points out that some industries, such as critical industries with high safety concerns, already have rigid software security controls. “But for other software products that are party to market forces, speed is the driving force: how fast can we get the product out? How fast can I put in a new feature and how fast can I get it released? That is a challenge when it comes to understanding the depth of how these components interrelate and documenting that, and then keeping it up to date. So, I do think that regulation is required.”
Reed Loden, VP of security at Teleport, has two specific suggestions. “Firstly, make the SBOM default generated via common CI/CD methods,” he recommends; “and secondly, require it as part of some compliance or legal obligation. Basically, you either need to have it be the ‘easy button’ and be available without any or much work, or explicitly require it (which will then cause the first one to happen, as people will want it done by default).”
Pedro Fortuna, CTO and co-founder of Jscrambler, has a solution. “To maximize the chances of SBOMs being useful, two problems must be addressed,” he says. Firstly, updated SBOMs must be generated and transmitted to consumers in a timely fashion. “This can be done by running an independent third-party runtime monitoring solution (which does not require cooperation from the software author) that can identify all software components dynamically and continually.”
Secondly the supply chain integrity must be validated. “The same runtime monitoring solution should verify that all sub-components’ integrity is pristine and that no malicious code is found running inside them,” he adds. The problem here is that if the monitoring solution is developed by independent third parties, there are likely to be many – and Morgan’s problem with inconsistent SBOMs will continue. But if the solution is developed by or for CISA, it will have to be imposed and not part of ‘shaping market forces’.
Varun Badhwar, CEO and co-founder at Endor Labs, believes that some form of more intrusive guidance is necessary to break the logjam of difficulties. “I’d love to see more regulatory guidance from CISA since they can work with other regulatory bodies to develop and publish guidelines that encourage or require the use of SBOMs in specific industries, such as critical infrastructure, government contracts, and software procurement processes,” he says.
“CISA could also advocate for financial incentives that encourage organizations to adopt SBOM practices. This might include tax breaks, grants, or other forms of financial support for companies that invest in SBOM implementation. The agency could take a similar approach to the OpenSSF in partnering with the vendors building SBOM technologies to highlight best practices and prepare companies for widespread SBOM adoption.”
This could indeed lead to a compromise between imposed regulation and market forces by establishing an industry consortium to encourage consistency in SBOM solutions. The only weakness here is that committees tend to create a camel when they try to design a racing horse.
The ultimate dream
It may simply be wrong to criticize CISA for an apparent lack of urgency over SBOMs. The agency has previous (UK slang warning) in patiently building a good idea into a valuable service. Consider the KEV list. In its early days it had little obvious value. But it kept growing and is now often used as a ready-made vulnerability triaging source – if the vulnerability exists in the KEV list, you automatically know it should be patched with some urgency.
The SBOM project is also proceeding slowly. What we don’t know is whether this is because CISA is feeling its way in the dark, or whether it is all part of a preconceived plan. The likelihood, however, is that even when realized, SBOMs will not completely solve the problem. “In the end, I believe more transparency is good,” comments Guillaume Ross, deputy CISO at JupiterOne. “But there’s no silver bullet in supply chain security, nor any part of cybersecurity in general.”
So, in answer to our original question, we likely won’t know for another decade whether the SBOM will become a success or remain a fantasy. All we know is that there will need to be a lot of work in the meantime.
Related: Cybersecurity Leaders Scramble to Decipher SBOM Mandate
Related: Chainguard Trains Spotlight on SBOM Quality Problem
Related: Video: A Civil Discourse on SBOMs
Related: Microsoft Releases Open Source Toolkit for Generating SBOMs
