If you’ve been around the computing industry lately, you’ve probably brushed against the term SBOM at some point or another. By now, it is common knowledge that a Software Bill of Materials (or SBOM) is becoming an increasingly expected requirement from software releases. Reading through blog posts and social media, there some confusion still persists about what an SBOM can do for your project. This post lays down some basic facts about SBOMs and how they can help you and your project become a better citizen of the global software supply chain.
What Exactly is an SBOM?
Have you ever noticed the packing slips attached to the sides of parcels when the UPS truck drops them? These packing slips contain several pieces of information that describe what is actually inside the box you are getting. It contains data about where it came from: the sender’s address, the time it was mailed, sometimes data about international customs the shipment may have traversed. It also contains data about the contents: it will generally contain a list of what is enclosed in the box, the quantities, the cost, and some other data which may prove helpful when checking if all your stuff is in there and it matches your order. The slip may also list some metadata about the manufacturing process that brought to life your items: lot number, model or generation of your product, serial number, and so on.
A Software Bill of Materials allows consumers and developers to do the same with software components plus a lot more. An SBOM is an electronic packing slip but with some additional superpowers!
The Two SBOM Standards
Most projects that produce or process SBOMs today will do so in one of two standards: CycloneDX and SPDX. These standards compete in a friendly way but also share ideas and the same final goal: give the world better introspection into software releases. Let us talk briefly about each one.
CycloneDX is sponsored by the Open Web Application Security Project (OWASP). It has a rich toolset with a lively community behind it. CycloneDX SBOMs have metadata associated with them and then describe sets of elements categorized as components, services, and dependencies. To tie all of these together, the SBOM defines compositions that define the relationships among the elements.
SPDX (The Software Package Data Exchange) is a project of the Linux Foundation. There are a number of tools written by the SPDX Team at the LF as well as several community written tools that can create and read SPDX SBOMs. The model of an SPDX SBOM defines three elements: Document, Package, and File.
The Ultimate Purpose(s) of the SBOM
SBOMs serve different purposes and can be leveraged by different kinds of users. If you are thinking about SBOMs for your project, consider that generating an SBOM takes you no further than the start line; the real value of an SBOM comes from actually using the information in it. Let’s go over some of the most common uses.
Locate and Describe a Software Component
An SBOM publishes data about a software component. The data contained within allows any link in the supply chain to locate a specific component in “space” and time: we can determine where a certain component was created and when. In addition, the SBOM informs consumers about who published the component and what they can do with it (licensing data).
Automation
In a complex system like a software supply chain, there would be little use for an SBOM if it did not enable the automated processing of its information. In the future, projects will be able to act on different pieces of machine-readable information contained in the documents. Do you need to be alerted of a compliance issue due to incompatible licensing? Done. A security alert in one of your dependencies? Your SBOM has you covered. Missing components in a software release? No problem. These are some of the common systems I’ve seen today but I am sure there are many others yet to come.
Licensing
As stated in the previous two points, SBOMs allow you to check the overall licensing compliance in your project. A software project may pull dozens or
even hundreds of dependencies, each of them released under a different license. If you skim the latest Kubernetes source SBOM for example, you’ll notice that the project pulls 236 dependencies released under eight different licenses:
Crossing this data with the SPDX license list allows you to check if your project is using software that restricts its usage or if you can confidently release your code as Open Source.
Security
Probably the most common use right now of the data in SBOMs is checking if you have security vulnerabilities in your dependencies. If a flaw is discovered in one of the libraries your code depends on, you can query the data in your SBOMs to determine if you are affected and find out which projects and versions are vulnerable.
But the story does not end at the dependency level. Your SBOM can help you find out if there is a problem with the base images you are using to create your containers. Properly defined, an SBOM will tell you the underlying layers a container image uses. If a vulnerability surfaces in one of your images, you can use your SBOM to check if you are using an affected hash.
Speaking of security, it is important to note that currently, trusting an SBOM requires signing and verifying it. While the SBOM provides the required data to cryptographically verify software components, the SBOM itself needs to be signed to enable consumers to check the integrity of the document itself.
Status of Tools and Cooperation
Working with SBOMs, meaning their creation, and consumption is still in the early stages of adoption. Tools still do different interpretations of the specifications in the way they express components and their metadata. Writing and consuming SBOMs is still a bit chaotic. The good news is that since the issuance of Executive Order 14028, (Executive Order on Improving the Nation's Cybersecurity) things are evolving rapidly thanks to different initiatives.
The Cybersecurity and Infrastructure Security Agency (CISA) recently hosted the SBOM-a-rama, a two-day event that, beyond its incredible name, brought together SBOM tool makers, government, and users across many, many industries to discuss use cases, tools, and future expectations. The Linux Foundation has the Automated Compliance Tooling project where SBOM tool maintainers are in constant discussion about the bill of materials landscape. The ACT-TAC incubates and supports the development of several SBOM tools like Tern, FOSSology, the OSS Review Toolkit, Quartermaster, and, most recently, the Kubernetes SBOM Tool. The LF also hosts the SPDX DocFest, a recurring event where tool writers run their tools against a common set of sample projects, and then the output of all of them is compared to work towards interoperability.
The Future: Your Tool Will Be SBOMin’ Soon
While producing and consuming SBOMs may seem daunting at times, the future is bright. As discussed in the previous paragraph, tools are working together to work towards interoperability and standards improvement. In the coming months, all of these efforts will result in better standalone tools, but the most important thing is that SBOM capabilities will start appearing in a tool near you.
I'd like to give a special shout-out to Batuhan Apaydin aka developer-guy and Furkan Türkal for spearheading this trend by raising awareness and building SBOM support into tools across the open source landscape!
At Chainguard, we are working with customers and open source projects to make this sort of seamless adoption a reality. Our mission is to make the supply chain secure by default, in part by building these kinds of modern supply chain technologies into them.
