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