Once upon a time, developers built and deployed software, and end users ran it, without thinking much about where the software came from. Those days are gone. Today, developers face increasing pressure to compile a so-called software bill of materials, or SBOM. SBOMs let end users, partners, regulators and other stakeholders know which components developers used when creating software, thereby providing greater visibility into the software supply chain.
Here’s a primer on what an SBOM is, why SBOMs are suddenly so important and how developers can build SBOMs for their applications.
What Is a Software Bill of Materials?
A software bill of materials is a list of the components that exist within a piece of software. For example, an SBOM may identify components such as:
- Software libraries or modules on which an application depends
- Third-party open source code that is directly embedded within an application
- Closed-source code or binaries supplied by vendors or partners that are built into an application
Why Are SBOMs Important?
The main benefit of an SBOM is that it ensures that various stakeholders know which components exist within the software they use. In turn, SBOMs allow users, partners, regulators and developers themselves to identify components that may be subject to security vulnerabilities.
This type of visibility has become particularly important in the present age of never-ending cyberattacks, an increasing number of which involve so-called supply chain breaches. In this type of attack, threat actors compromise software that is used by organizations other than the one that developed the software. Thus, attackers can breach “downstream” victims by compromising the software that is supplied to them.
While SBOMs alone don’t prevent software supply chain attacks, they can help businesses know whether they’re vulnerable to such an attack based on the components in the software they use.
How Long Have SBOMs Existed?
Software bills of materials are a new application of an old concept. In supply chain management, vendors have long generated bills of materials to identify the various parts that form their products. The ingredients list on food you buy in the grocery store, for instance, is essentially a BOM.
The importation of the BOM concept into the realm of software, however, is newer. It didn’t gain widespread attention until May 2021, when the Biden administration issued an executive order pointing to (among other things) SBOMs as a means of improving cybersecurity in the United States. The order also requires software vendors that sell to the U.S. federal government to supply SBOMs for their products.
Who needs an SBOM?
The SBOM executive order applies only to vendors that do business with the U.S. government, and, to date, no major compliance framework has adopted requirements related to SBOMs.
Thus, most companies don’t need to generate SBOMs, strictly speaking. However, in the wake of the federal rule regarding SBOMs for government vendors, as well as the increasing prevalence of supply chain attacks, providing SBOMs is likely to become a requirement for more and more businesses going forward. If you don’t already create SBOMs for the software you build, now is a good time to start.
How to Create a Software Bill of Materials
You can, of course, compile an SBOM bill by hand by manually listing out the various components within software you have created. But that’s a tedious and time-consuming process, especially for developers who maintain large codebases with dozens or even hundreds of dependencies and third-party components.
Manual SBOM creation can also be tricky for teams that maintain large codebases written by many different developers over a period of time. In that case, some developers may have incorporated third-party components into an application without having documented doing so. As a result, current developers may be unsure of everything in the codebase.
A better approach is to take advantage of the growing number of tools designed to help developers create SBOMs automatically. The two main open source solutions in this category include:
- SPDX, a CLI tool that integrates SBOM generation with package management
- CycloneDX CLI, which generates SBOMs based on OWASP’s CycloneDX standard
Developers can find SBOM generation tools from vendors as well, such as Fossa and DependencyTrack.
Finally, source composition analysis (SCA) tools can be useful in building an SBOM. Although SCA tools don’t generate SBOMs themselves, they can identify the origins of components within a codebase, thereby making it easier for development teams to figure out exactly what is in their source code in cases where programmers may have borrowed third-party components without realizing (or documenting) it.
Conclusion: The Future of SBOM
In short, although SBOM remains a relatively new concept for most developers, the ability to generate SBOMs is likely to become increasingly important going forward. If you haven’t begun integrating SBOM production into your software delivery process, now’s a great time to evaluate the tools available to help you do so.