TL;DR Tired of fretting about SBOM formats rather than focusing on software supply chain security? A new open source tool, `protobom,` frees you of this burden, helping you and your organization create and consume SBOMs regardless of SBOM format.
If your company is trying to improve its software supply chain security, would you rather focus on creating and analyzing rich metadata about the software components in your company’s product? Or would you rather be creating powerpoint slides about the differences between software bill of material (SBOM) formats so that someone who knows even less than you about SBOM formats can make a decision about which SBOM format your company should use?
To use a familiar computer analogy, if your company was discussing standardizing on JPEG or PNG graphic forms, you might think that everyone at your company had lost their mind. Unless you work as a graphic design artist, you most likely don’t care and would rather that software handle this matter as an implementation detail. SBOMs should be the same. (We expect this statement to anger some readers. Counter-arguments welcome. Please send us a link when you publish it.)
For those readers who prefer to focus on software supply chain security rather than implementation details, a new open source library, `protobom`, is for you. This tool offers a format-neutral representation of SBOM package and file data and the ability to translate this data between popular SBOM formats. SBOM tool builders can stop sweating format-specific details and, in the long run, SBOM users can stop worrying about which format is “better.”
This post describes the motivation and origin story for `protobom` and outlines how the tool works. Parties more interested in code than prose can skip this blog post though and simply join the fun here: https://github.com/bom-squad/protobom. Issues, pull requests, and collaboration welcome!
Why making SBOMs is better than making SBOM format war
Those parties interested in software supply chain security, especially companies, governments, security engineers and software developers, often arrive at a fork in the road when learning about and adopting SBOMs: what format to use. There are two popular formats, which this article will call format #1 and format #2 to emphasize that these details should not be important.
These parties then spend time reading specification documents, testing out existing tooling, and analyzing the governance structure of both communities. There is now even a cottage industry of blog posts comparing format #1 and format #2. (We refuse to provide any links since you should not have to read these.) Those committed to software supply chain security then are forced to choose a side in the format wars to avoid the headache of supporting both formats.
But why? Seriously, why? To use an analogy familiar to most computer users, you have probably used or viewed different graphics formats (such as JPEG or PNG), but you most likely didn’t really care and just let the software handle this matter as an implementation detail. SBOMs should be the same. (We expect this statement to anger some readers. Counter-arguments welcome. Please send us a link when you publish it.)
Organizations and individuals interested in software supply chain security and in creating rich metadata about the composition of their software should be able to focus on that mission. That’s why the United States Department of Homeland Security, specifically the Directorate of Science and Technology’s Silicon Valley Innovation Program, has funded seven companies, including Chainguard, to build `protobom` and other SBOM-related tools.
Protobom: What it is and how it works
`Protobom` is an open source tool that provides a neutral representation of SBOM file and package metadata and the way they relate to each other. It allows other SBOM tools to translate SBOMs between format #1 and format #2 (or, in the future, other formats), which means that SBOM users can stop worrying about SBOM implementation details.
For readers interested in technical details, the `protobom` GitHub repository is a protocol buffers representation of SBOM data. Consider this representation the “Switzerland” of SBOM data formats. The representation uses a node list data structure to abstract away the details of format #1 and format #2. While the initial implementation is written in Go, protocol buffers support many languages and future versions of this library can potentially support other languages. There is also an initial application built using for protobom in a separate repository, also hosted on the “bom-squad” GitHub organization created by the DHS-funded cohort of companies.
While `protobom` is intended to perform ingestion of SBOM file information and package information without loss, there is inevitably some “lossiness” when converting between format #1 and format #2. Future versions of the tool will include debugging information that clearly describes all data loss to enable consumers. The collective hope of this tool’s creators is that the data loss is minimal and easily understood and, hopefully, of little consequence to the end-user consuming and analyzing an SBOM.
Make SBOMs, not SBOM format war
If SBOM advocates want to start using the SBOMs we build, then it’s probably time to call a truce on the SBOM format wars. Consider `protobom’ the white flag inviting all parties to stop fighting over SBOM formats and to start making SBOMs useful.
And if you’re interested in creating, ingesting, and analyzing the SBOMs in your software--no matter the format--consider contacting Chainguard and learning about the cloud workload SBOM ingestion and analysis capabilities of Chainguard Enforce and the SBOMs associated with Chainguard Images.
