Introducing the Developer’s Guide to SBOMs

As a concept, the Software Bill of Materials (SBOM) isn’t particularly complex: it’s a manifest that identifies the components that make up a particular software artifact.

When we start looking at the practical implementation of SBOMs, however, a lot of complexity is suddenly introduced into the equation. You might be wondering what actually goes into an SBOM, how SBOMs identify components and represent dependency graphs, or what the term “software artifact” even refers to. To help answer these questions and clarify any confusion surrounding SBOMs, we are excited to introduce the Developer’s Guide to SBOMs.

SBOMs have been recognized as a necessary component of a secure software supply chain, because it’s impossible to keep vulnerable components away from security-critical applications without understanding the composition (provenance) of those components. Meant to help you better understand why SBOMs matter, the Developer’s Guide to SBOMs has critical information for every audience:

• If you’re a developer, DevOps engineer, technical lead, or business stakeholder and haven’t heard of SBOMs before now, our guide is for you. It’s very likely that, in the near future, you will have a consumer of your software request a Software Bill of Materials, and we hope this guide will help you prepare.
• Likewise, if you are now encountering SBOMs because users of your software are beginning to request these manifests, the Developer’s Guide will help you wrap your head around this emerging subject. Seeing how SBOMs can integrate into your existing development workflow will help you understand the practical challenges of assessing software provenance.
• Even if you maintain an open-source project with few commercial users, assembling an SBOM for each release can help you communicate the security posture of the project to potential users. Open source projects face many of the same challenges as commercial software when it comes to assessing the security of a given asset, and SBOMs are a direct response to these long-standing security challenges.

No matter who you are, you’re likely to encounter this topic again very soon. In May 2021, President Joe Biden signed an executive order which directs the United States to “use the purchasing power of the Federal Government to drive the market to build security into all software from the ground up.” As more organizations begin to demand SBOMs from their suppliers (to fulfill the terms of government contracts and comply with new regulatory requirements), a cryptographically-verifiable SBOM describing the provenance of a software artifact will become as important for assessing an artifact’s integrity as the developer’s signature on the final asset itself.

As this guide launches, it contains a high-level explanation of SBOMs—exploring the concepts and standards critical for working with SBOMs—as well as a practical introduction to handling SBOMs through the lens of the tools we’re building here at Codenotary. We hope to expand this guide to become your first stop for everything you need to know to bring SBOMs into your development workflow.

If you have any questions left unanswered by the Developer’s Guide to SBOMs, we hope you’ll discuss your feedback with us on GitHub!