The software bill of materials, often referred to as an SBoM or BOM, has gained a tremendous amount of popularity in the past year and a half. It’s mentioned in the US White House’s 14028 Executive Order and is referenced in innumerable secure software supply chain articles. While the SBoM concept has been around for many years, awareness and adoption seems to be hitting an inflection point.
The simplicity of an SBoM
The SBoM’s growth in popularity owes credit to its simplicity, especially compared to other tools in the software supply chain. At its core, an SBoM is a list of an application’s software packages or dependencies. It’s an inventory of the open source, third-party, or internal components a developer is using to build an application.
It starts with the ingredients. The oft-cited, ubiquitous analogy is that an SBoM is the list of ingredients on, say, a loaf of bread’s nutrition label, or the specific ingredients on your grocery shopping list for the spaghetti recipe you intend to make for dinner.
Why are ingredients helpful? Let’s examine the strengths of an SBoM.
Source: Sugarbird Sweets
Data-driven decisions
Are you intolerant of gluten, or are you looking to cut down on your sugar intake? Without scrutinizing a food product’s inputs, it’s impossible to know whether you should consume it. In an identical way, SBoMs help you answer questions such as: Does the software package have vulnerabilities or other security risks? Are you using an old version? Is the software license compliant with your company’s standards? SBoMs are the first prerequisite toward meeting organizational security and compliance requirements.
Standardization
The Food and Drug Administration requires all food products to contain a consistent label. This makes it easier for consumers to understand the information. The same benefit applies to SBoMs. The software industry has largely agreed on one of three SBoM formats: SPDX and CycloneDX, which are geared toward developers, and SWID, which is geared toward software on managed devices, such as medical instruments. Consensus on these machine-readable standards is a key for scaling SBoMs.
Save the label
The label imagined above includes other details besides the primary ingredients: “compound” ingredients (e.g., mixed berries [strawberries, raspberries, … ]), the company that produced the product, where to find the company (i.e., an address, a website), a product expiration date, and a serial number. As a consumer, perhaps you don’t immediately care about this for your “eat or don’t eat” decision. But let’s say you discover a carton of eggs in your fridge and you can’t remember when you bought them. If you’ve saved the label and expiration date, you can prevent an upset stomach. Or, if there’s a recall on a product, having the label and serial number to see if your product is affected can help you make a similar determination.
In the same way, SBoMs contain metadata that you can reference when a new vulnerability is discovered long after you’ve made the decision to use a given software package. Saving all your SBoMs, and making them easy to access, will pay itself back any time something changes relating to your software dependencies.
Simplicity doesn’t equal ease
It’s easy to understand the concepts and the benefits of SBoMs, but it’s much harder to actually implement them. After all, it’s one thing to manually examine a few items for gluten than it is to save and monitor ingredients for every food product for the rest of your life.
The primary difficulties with a consistent SBoM diet are:
-
Having complete SBoM metadata
-
Generating SBoMs at the right moment in your supply chain
-
Storing and accessing SBoMs
These challenges, and more, are outlined in the National Telecommunications and Information Administration’s extensive SBoM content, including in the Minimum Elements for a Software Bill of Materials document, produced as part of the White House’s Executive Order mandate.
Completeness
SBoMs need to be complete to be useful. While the SBOM formats (e.g., SPDX) provide schemas that support a robust set of data, including the minimum data the NTIA recommends, it doesn’t mean that the data will be provided.
Source: National Telecommunications and Information Administration
The complexity arises due to a number of factors. One major driver is transitive dependencies, which are dependencies of dependencies. If you are the maintainer of an open source project with no software dependencies, you can create a perfectly complete SBoM since you have all the information at your fingertips. But, if you rely on upstream software, and if that software relies on other software, the SBoM you generate will likely be missing certain data, such as the dependency relationship or unique identifier.
There is no real solution to this, just an acknowledgement that your SBoMs will only be as complete as the upstream software you are using. As SBoM adoption increases, SBoM completeness will improve. This is all the more reason to generate and share your SBoMs with your software users.
When to generate SBoMs
Closely related to completeness is the timing of SBoM generation. Going back to our food label analogy, if the loaf of bread is missing its label once you’ve arrived home but you’re determined to re-create one, you’ll likely be able to correctly guess some of the ingredients but will certainly miss others.
In the same way, SBoMs have an ideal time in the “manufacturing” process for generation. Specifically when software is being “built” into a binary (i.e., image), certain additional software dependencies are introduced. These should be captured in the SBoM, but they can be missed if the SBoM is generated before or after this stage in the software supply chain. Automating SBoM creation during an automated build process is ideal.
Paketo Buildpacks is an open source project that automatically generates an SBoM when building the image. VMware Tanzu Build Service is a commercial offering that offers the same functionality out of the box.
Storing and access
How does one keep up with every SBoM? It’s a very large task. If we assume you generate an SBoM for every git repo and image in your enterprise, after every build, and many of your repos and images having 10, 100, or 1,000 packages, this equals a huge quantity of data. Additionally, the data is only helpful if you can efficiently access it. When the next “log4j” package arises, you need to be able to query your entire enterprise’s SBoMs to see which repos and images contain “log4j.”
A relational database is the obvious solution for keeping track of all this data.
The Store feature in the supply chain security tools available in VMware Tanzu Application Platform was created for this specific need. It comes with a CLI tool to help answer questions like what images contain a certain CVE or software package (see demo video).
Software’s nutrition label moment
The Federal Food, Drug, and Cosmetic Act (FDCA) of 1938 paved the path for standardized nutrition labels across all food products. Perhaps the following passage from the White House’s May 12, 2021, executive order will be looked at in a similar light for software:
Sec. 4 (e) (vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website
When the US government requires its software vendors to provide an SBoM, it seems likely to have a large trickle-up effect to all upstream software providers.
The SBoM is only one tool in a wide-ranging security tool belt. It has its weaknesses, such as a lack of built-in tamperproofing (i.e., if a malicious user were able to edit an SBoM, it would make the software user blind to vulnerabilities). However, SBoMs will see many rounds of evolution as more people and companies start using them regularly, in the same way that there have been many laws and acts to improve upon the original FDA nutrition label act. The current nutrition label is quite different from one created 50 years ago, and there will continue to be iterations in the future.
One way to begin exploring SBoMs is to check out Tanzu Application Platform. The related documentation will help you experiment with scanning and storing your software dependencies. However, the most important takeaway is to start reading and organizing your software’s nutrition labels. Start generating SBoMs manually; it’s very simple to do. Start cross-referencing your software’s dependencies with vulnerabilities. Start organizing and storing the dependencies. You’ll be well on your way toward establishing a healthy SBoM routine.
