Thursday, June 2, 2022

The other Minimum Elements of an SBOM


Probably the most widely-read of the 20-odd documents that were produced by the NTIA on SBOMs was “The Minimum Elements for a Software Bill of Materials”. Of course, this document was mandated by Executive Order 14028, which required that federal agencies start requesting SBOMs from their suppliers of critical software, but didn’t itself provide further information about those SBOMs.

I think this is a very well-written paper, which provides a lot of good information on what should be in an SBOM, as well as how it should be produced.[i] But literally 80-90% of the minimum elements mentioned in the paper have been totally ignored by the software community. This becomes clear if you look at the table on page 3 of the document.

The table lists three areas of minimum elements that will be discussed in the document: Data Fields, Automation Support, and Practices and Processes. Yet I’m not exaggerating when I say that literally 100% of what I’ve seen written about the minimum elements of an SBOM just addresses the data fields – i.e., the seven fields that need to be in an SBOM. Everything I’ve read ignores the minimum elements found in the other two areas.

This is too bad, since the NTIA made some excellent observations in those two areas. The reason for this neglect is quite simple: On page 9 of the document, you can find a nice table of the seven minimum data fields (called “baseline data elements”). But there’s no equivalent table for Automation Support or for Practices and Processes. You have to read a bunch of – shudder! – text and make your own tables. With hindsight, it would have been good to include summary tables for the other two areas as well.

This post is an attempt to make up for that omission, although the information won’t be in tables, but in lists. However, I first want to point out that nothing in the Minimum Elements document is “required” of federal agencies this August, when compliance with Section 4(e) of the EO is due. The only actual requirement for SBOMs under the EO is that agencies start asking their suppliers for them; that doesn’t require any minimum elements – just an email saying, “Please send me an SBOM.”

On the other hand, everything in the document is worth considering as you develop your organization’s program to utilize or produce SBOMs – and that goes for all organizations that use software, not just federal agencies.

Automation Support

Automation Support is discussed on pages 10 and 11. There’s just one “element” in this section: An SBOM should be provided in one of the three machine-readable formats: SPDX, CycloneDX or SWID[ii].

I do want to point out that there are other important considerations for automation support, that were probably left out of the Minimum Elements document because that’s all they are: considerations. One is that both SPDX and CycloneDX are available in different data representation schemes, the two most important of which are JSON and XML. Both SPDX and CycloneDX also support good ol’ XLS, which is machine-readable but is mainly intended for eyeballs – and can’t easily convey a lot of the information that’s provided using the JSON and XML schemes.

Practices and Processes

Most minimum elements are found in this category. They include the following (with references to the appropriate page of the document):

Frequency (page 12): This is very simple, but also very important. An SBOM should be re-issued whenever the software has changed. Of course, this includes major and minor updates, but it also includes patches. In my opinion, the version string should also change whenever there’s been a software change, even just a patch. Having separate “patch levels” or “build levels” isn’t going to work anymore, since none of the automated SBOM tools is likely to support either of those. So, patch levels and build levels will need to be integrated into the version string. If that isn’t done, there will be multiple SBOMs with different content, that are considered by the SBOM tooling to be identical. That obviously won’t work.

Depth (page 12): I will admit that people who engage in the reprehensible practice of writing about SBOM practices (which includes me, I’m ashamed to say) often speak of an SBOM as an inherently multilayer document. That is, we often make it seem like everyone should expect every SBOM they receive to show the direct components (dependencies) of the product itself, as well as the second, third, fourth, etc. layers – yea, unto the 15th or 20th generation.

There are two problems with this. First, the idea of neat, nested layers of components isn’t accurate in practice. There’s nothing that prevents component B from being a dependency of component A, while at the same time a different instance of A is a dependency of B – within the same product. However, it’s still accurate to take a particular chain of dependencies and put those in hierarchical order. In practice, it’s impossible not to talk about “layers”; you just need to understand what that means.

The second problem is much more important: It’s very hard for a supplier to get information on anything more than the first “layer” of components. And here’s where NTIA’s advice kicks in: “At a minimum, all top-level dependencies must be listed with enough detail to seek out the transitive dependencies recursively.” This means that:

1.      The supplier needs to provide their users a complete list of first-level components in their product (after all, if a software supplier doesn’t even have a complete list of the components that the supplier themselves included in their product, perhaps they ought to think about finding another line of work…); and

2.      The supplier needs to name the first-level components with enough accuracy that the user will be able to seek out an SBOM for each of those components (see below). In my opinion, the supplier should also make their best effort to acquire the SBOM for each first-level component, so they can fill in at least some of the “second layer” components in their SBOM.[iii]

For the time being, it’s better for software users not to demand too much from their suppliers. Just getting a complete list of components from their supplier (with usable identifiers like CPE and PURL for each one, so they can be looked up in vulnerability databases) will be a big improvement over the SBOMs that most users have currently, which are none at all.

Distribution and delivery (pp 12 & 13): The document doesn’t prescribe any means of distribution and delivery of SBOMs, but does say there are two components to this: “..how the existence and availability of the SBOM is (sic) made known (advertisement or discovery) and how the SBOM is retrieved by, or transmitted to, those who have the appropriate permissions (access).”

And here I disagree with the document. I believe that, once SBOMs and VEX documents are being widely produced and used (which might well be 5-10 years from now, I’ll admit), any distribution and delivery mechanism that depends on the end user retrieving the SBOM themselves, or even requesting it, will ultimately fail. What’s needed long-term is literally a mechanism to “stream” SBOMs and VEXes to users (more specifically, to the tool they operate to “process” the two documents for supply chain cyber risk management purposes), so that they don’t have to do anything at all to receive the documents they’re entitled to; they just show up. I described that mechanism (in not much detail) at the end of this post. 

I’ve gone through all the Minimum Elements listed in the NTIA document, except for the seven minimum data elements and a couple other minimum elements that I don’t think are important. However, the document also goes “Beyond the Minimum Elements” and discusses some things that are probably not needed now, but which will be important in the future – so the user needs to be thinking about them. Rather than load them into this already-full post, I’ll discuss them soon.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.


[i] The document says nothing about how government agencies (and by implication, other software users) can utilize SBOMs for cybersecurity risk management purposes. Use of SBOMs remains an under-addressed area, although that is changing.

[ii] SWID really isn’t an SBOM format; it’s a machine-readable software identifier. It does include the seven minimum fields but very little else, making it not very useful for most SBOM purposes, including software supply chain risk management. But, since properly identifying software components is a big problem that several groups are working on now, SWID may see expanded use in coming years. It may well be a component (no pun intended) of the solution to that problem.

[iii] I think intelligent (IoT) device suppliers have a special obligation to try to obtain SBOMs for the first-level components. I’ve written an article on SBOMs for IoT and IIoT devices with my customer Red Alert Labs, which explains why I say this. When it’s published in July, I’ll publicize it in my blog.

No comments:

Post a Comment