SBOM Everywhere: The OpenSSF Plan for SBOMs
The Open Source Security Foundation (OpenSSF) has published a mobilization plan to improve the resiliency and security of open source software (OSS). Modern software supply chains leverage OSS extensively because it affords faster innovation and better-quality products, but its broad adoption comes with risk due to inherent vulnerabilities in OSS components.
An important component of the plan is using a software bill of materials, or SBOM, as a foundational building block to improve the security posture of the entire open source ecosystem. The plan outlines how OSS projects should provide SBOMs to downstream users, providing a new level of visibility into OSS components. As a result, organizations using OSS will now need a set of processes for SBOM management, enabling them to generate, ingest, analyze, store, monitor and share SBOMs to improve the security of their own software supply chain.
What Does SBOM Everywhere Mean?
The Open Source Software Security Mobilization Plan contains 10 action items referred to as “activity streams.” The goal of Stream 9, called “SBOM Everywhere: Improve SBOM Tooling and Training to Drive Adoption,” is to help drive the adoption of SBOMs as a foundational building block to improve the security posture of the entire open source ecosystem. The core idea is to enable OSS ecosystems to deliver an accurate SBOM for each release of their software. For OSS producers, consumers and maintainers, an SBOM serves as the definitive list of all components within a software product and can be used to identify existing and new vulnerabilities at every stage of the software development life cycle.
The SBOM Everywhere working group will focus on ensuring that existing SBOM formats match documented use cases and developing high-quality open source tools to create SBOM documents. Although some of this tooling exists today, more tooling will need to be built. The working group has also been tasked with developing awareness and education campaigns to drive SBOM adoption across open source, government and commercial industry ecosystems.
Notably, the U.S. federal government has taken a proactive stance on requiring the use of SBOMs for all software consumed and produced by government agencies. The Executive Order on Improving the Nation’s Cybersecurity cites the increased frequency and sophistication of cyberattacks as a catalyst for the public and private sectors to join forces to better secure software supply chains. Among the mandates is the requirement to use SBOMs to enhance software supply chain security. For government agencies and the commercial software vendors who partner and sell to them, the SBOM-fueled future is already here.
What Will this New SBOM-Driven Future Look Like?
The pioneering computer scientist Alan Kay famously said, “The best way to predict the future is to invent it.” The evolution of the SBOM will most certainly be an exercise in invention. As we use SBOMs, we will find new ways to improve and build on top of what we have today. Here’s a sneak peek at the SBOM of the future:
Multiple SBOM Formats
Multiple SBOM standards exist today, and we can expect these to evolve and for others to be created. The two most popular SBOM formats are SPDX and CycloneDX. There are tools for converting one SBOM format into another, but you should expect to use all formats at some point as long as multiple standards exist. Although one format may emerge as the industry standard, it’s more likely that we will need to continue to use multiple formats and also create purpose-built formats to support future requirements. Rather than trying to pick a winner now, it will be important for OSS consumers to have tools that enables them to support the multiple formats.
Ingesting and Generating SBOMs
Many of the things we run and build are really a lot of smaller pieces put together to create something larger. Similarly, modern software applications are built using hundreds or even thousands of smaller building blocks, comparable to using multiple Lego sets that easily snap together. Just as we combine components to build software, we will need to combine SBOMs from each component to make a comprehensive SBOM for a particular application.
The SBOMs for the components we use may come from OSS projects or from commercial software providers, or we may need to generate SBOMs for some components ourselves. It will be important to have the ability to ingest these component-level SBOMs in different formats and then assemble them to create one larger, comprehensive SBOM that reflects the final application that was built.
Assembling and Outputting SBOMs
Once we assemble our application-level SBOM, we will use and share it internally (for security and compliance purposes) and potentially distribute it externally to customers and users. We will ingest SBOMs for existing software, generate new SBOMs for new software we create and then output SBOMs that encompass all of the components of the final applications. The process of outputting SBOMs may be complex and daunting without tools to help us manage SBOMs. Most applications will have multiple versions of SBOMs for hundreds of individual pieces that all need to be combined into the final SBOM. Without SBOM tooling, it will be an impossible task to track and accurately create application SBOMs.
SBOM Management
The ability to manage SBOMs will support myriad use cases that will continue to evolve over time. Currently the primary focus of the SBOM Everywhere stream is to use SBOMs for vulnerability scanning. Maintaining a repository of all of the SBOMs in your software applications allows you to go beyond simple point-in-time scanning to continual monitoring of your SBOMs for new vulnerabilities that arise, even post-deployment. Additional use cases for SBOM management include maintaining an inventory of your software components, verifying what you are using against what the project contributors think they shipped, gaining visibility into open source licenses, and assessing the health and risk of OSS projects you use. There almost certainly will be other uses for leveraging SBOM data in the future.
4 Steps for Getting Started with SBOMs
The sooner we all start to use SBOMs, the faster we can invent a future where we can improve the security of our software supply chains. These are the steps you can take right now:
1. Learn about SBOMs.
One focus of the SBOM Everywhere initiative is awareness and education. There’s little formal education available for SBOMs, but there are many resources for self-education such as these from CISA, CycloneDX, and SPDX, and this blog post from Anchore on Key Things to Know About SBOMs and SBOM Standards. By starting your learning now and contributing to the growing awareness of SBOMs, you will be better prepared for the future state of SBOMs.
2. Generate SBOMs.
Start generating SBOMs for the software you build or for open source components you use. There are many open source tools available, including docker sbom, Syft and GoReleaser, to name a few. By creating SBOMs for the software we build and deploy, we can help understand what the best way to share SBOMs will look like. It also helps normalize the process for everyone else.
3. Request SBOMs.
Ask for SBOMs from your open source project maintainers as well as commercial software vendors. Not everyone is ready to create and share SBOMs, but asking now is how we start. The more frequently customers and users ask for an SBOM, the greater the likelihood that the SBOM will top the feature request list. For open source projects, you should expect to help with the SBOM generation process because we can’t make demands of our open source maintainers, but we can submit patches.
4. Set expectations for SBOM adoption.
Lastly, the most important thing for us all to do is to have reasonable expectations as we navigate a new SBOM-driven world. We will collectively learn a great deal as we celebrate success and persevere through failure. Having patience and understanding for each other while we figure out how to create, manage and output SBOMs will ultimately help us progress further and faster to an “SBOM everywhere” future.
By adopting the SBOM as a best practice to secure the commonly used OSS components that create shared dependencies within the larger ecosystem, we can vastly improve security across the entire software supply chain.
To get started, here’s a resource to generate an SBOM with free open source tools.
