What an SBOM Can Do for You

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 is becoming an increasingly expected requirement from software releases. Reading through blog posts and social media, there still seems that some confusion persists about what an SBOM can/could do for your project. This post tries to lay 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 Is Exactly 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 and/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 a 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.

• Document defines metadata about the SBOM
• Package is a concept that groups together one or more elements
• File is, well, pretty much self-explanatory: a single file.

One big difference between SPDX and CycloneDX is the rich set of
relationship kinds that the SBOM can express about its elements. For example, a file can be CONTAINED_BY a package, while the package is a PACKAGE_OF that same file. The relationships expressed in an SPDX SBOM can be very accurate and quickly become quite complex (in a good way!).

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:

PackageLicenseInfoFromFiles: Apache-2.0
PackageLicenseInfoFromFiles: BSD-2-Clause
PackageLicenseInfoFromFiles: BSD-3-Clause
PackageLicenseInfoFromFiles: CC-BY-SA-4.0
PackageLicenseInfoFromFiles: GPL-2.0-only
PackageLicenseInfoFromFiles: ISC
PackageLicenseInfoFromFiles: LGPL-3.0-only
PackageLicenseInfoFromFiles: MIT

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.

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.

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.

Most of the tools listed above also offer open source libraries that can be reused in other projects to add SBOM support, and we already have some examples out there: Last month, GoReleaser added to its magic powers a feature to create SBOMs. The popular ko image building tool now creates SPDX documents describing the Go dependencies of the images it creates. publish-release, a simple utility to create GitHub releases maintained by the Kubernetes Release Engineering team now writes an SBOM when cutting a new release. Like these tools, you can expect SBOM capabilities to crop up in the coming months in software you currently use.

I'd like to give a special shout-out to Batuhan Apaydin aka develper-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.

from Hacker News https://ift.tt/3tzpXMe