An SBOM is a formal, structured record that not only details the components of a software product, but also describes their supply chain relationship. An SBOM outlines both what packages and libraries went into your application and the relationship between those packages and libraries and other upstream projects—something that’s of particular importance when it comes to reused code and open source.
You might be familiar with a bill of materials for an automobile. This is a document that goes into great detail about every component that makes your new car run. The auto supply chain is notoriously complex, and even though your car was assembled by Toyota or General Motors, many of its component parts were built by subcontractors around the world. The bill of materials tells you where each of those parts came from, and that knowledge isn’t just an interesting bit of trivia. If a certain production run of airbags has been recalled, car manufacturers need a quick way to know where those particular airbags ended up.
Writing software isn’t exactly like manufacturing a car, but with increasing use of third-party open source libraries to build containerized, distributed applications, the two processes have more in common than you might think. That’s why SBOMs are becoming more and more common.
Developers and users alike can use an SBOM to understand what exactly has gone into the software they distribute and use. That has a number of important implications, especially for security.
Why do you need an SBOM?
The days of monolithic, proprietary software codebases are long over. Modern applications are often built on top of extensive code reuse, often using open source libraries. These applications are also increasingly broken into smaller, self-contained components of functionality known as containers, managed by container orchestration platforms like Kubernetes and running locally or in the cloud.
Overall, these changes have been a boon for software development, and have certainly increased developer productivity and reduced costs. But in many ways they’ve been a nightmare for security. By relying heavily on third-party code whose inner workings they may not be fully familiar with, developers have created a supply chain of software components every bit as complex as the ones used by physical manufacturers. And because an application is only as secure as its least secure component, software built in this way has unique vulnerabilities that the industry is deep into grappling with.
The 2020s so far have been marked by a string of headline-making software supply chain attacks. In late 2020, hackers affiliated with Russian intelligence managed to plant backdoors into a network monitoring platform from SolarWinds—a platform that is used in turn by other security products, all of which ended up compromised. And late in 2021, a severe vulnerability was discovered in a Apache Log4j, a Java library used for logging system events, which sounds boring until you realize that almost every Java application uses Log4j in some capacity, rendering them all targets.
These security crises illustrate the role that an SBOM can serve in the security landscape. Many users might have heard in passing about these vulnerabilities, but were blissfully unaware that they were running Log4j or any SolarWinds component. With a proper SBOM, you would know exactly which packages you had deployed—and, more to the point, what version of those packages, which would allow you to update as needed to stay safe.
SBOMs can go beyond security as well. For instance, they can help developers keep track of the open source licenses for their various software components, which is important when it comes to distributing your application.
Software bill of materials executive order
The SolarWinds hack in particular raised alarms in the U.S. government, as many federal agencies had deployed the compromised component. That’s why a major cybersecurity executive order issued in May included directives on SBOMs. Specifically, the Commerce Department was directed to publish a baseline of minimum elements for SBOMs, which would then become a requirement for any vendor selling to the federal government.
Although the order applies specifically to those with direct relationships with the Feds, the sprawling nature of the U.S. government and the many companies eager to work with it will have knock-on effects; and after all, the products being sold to the government, which now come with an SBOM detailing their components, are for the most part being sold to other companies and organizations as well. Many software manufacturers hope that, even though they’ve been nudged in this direction by the government, their private sector customers will also see SBOMs as a value-add.
Plus, federal contracting is itself a supply chain. “There are only so many companies that directly do business with the federal government, and they’re going to be obviously directly impacted,” Sounil Yu, former chief security scientist at Bank of America and now CISO and head of research at JupiterOne, told CSO when the executive order was rolled out. “The second-order effect, those companies that sell to those companies that sell to the federal government, is much greater.”
What should be included in an SBOM?
In response to the executive order, in July 2021, the National Telecommunications and Information Administration (NTIA) released “The Minimum Elements For a Software Bill of Materials,” which outlined what an SBOM would need to meet the requirements of the federal government. Again, because of the dominant position federal contracting has within the economy, it was expected that this document would become a de facto standard for SBOMs across the industry. The NTIA laid out seven data fields that any SBOM should have:
- Supplier name: The name of an entity that creates, defines, and identifies a component.
- Component name: The designation assigned to a unit of software defined by the original supplier.
- Version of the component: An identifier used by the supplier to specify a change in software from a previously identified version.
- Other unique identifiers: Other identifiers that are used to identify a component, or serve as a look-up key for relevant databases. For example, this could be an identifier from NIST’s CPE Dictionary.
- Dependency relationship: Characterizing the relationship that an upstream component X is included in software Y. This is particularly important for open source projects.
- Author of SBOM data: The name of the entity that creates the SBOM data for this component.
- Timestamp: Record of the date and time of the SBOM data assembly.
SBOMs must also meet these requirements:
- The SBOM be in one of three standardized formats—SPDX, CycloneDX, or SWID tags— so that it can be machine readable
- A new SBOM must be generated with each new software version, ensuring that they’re up to date.
- In addition to including dependency relationships, the SBOM must explain where such relationships probably exist but are unknown to the organization putting together the SBOM.
How to generate an SBOM
Reading this article, you might find the prospect of generating and SBOM rather daunting. After all, manually tracking down all those decencies has to be a nightmare, right? Well, fortunately, that isn’t anything you’d be expected to do. In most cases, SBOMs are automatically generated by software composition analysis (SCA) tools. SCA tools are frequently used within DevSecOps pipelines and often play roles beyond SBOM creation.
SCA tools will scan your code directories for packages and compare them against online databases to match them with known libraries. There are alternatives to this as well: for instance, there are some tools that will simply create an SBOM as part of the software build process.
The OWASP Foundation, the venerable security-focused org that developed the CycloneDX standard, has brought together a fairly comprehensive list of SCA tools. This list is instructive because it runs the gamut from bare bones, open source command line tools to flashy commercial products. If you’d like to take a deeper dive into this product space, CSO’s “7 top software supply chain security tools” focuses heavily on tools for generating SBOMs and provides some relatively in-depth discussion of our recommendation.
If building distributed software, it’s becoming increasingly important that you integrate SBOMs into your development practice. You may not be contracting with the federal government (or may not be contracting with them yet), but you almost certainly have to worry about supply chain attacks, and SBOMs offer a peek into the black box that is third-party reused code.
Copyright © 2022 IDG Communications, Inc.
