The NTIA Minimum Elements document contains this short paragraph (on page 12, for those keeping score at home):
An SBOM should contain all primary
(top level) components, with all their transitive dependencies listed. At a
minimum, all top-level dependencies must be listed with enough detail to seek
out the transitive dependencies recursively.
Translated into English, this says
that an SBOM “must” list all the “first level” components – meaning those that
are direct dependencies of the product itself (although remember, this document
is just supposed to contain suggested guidelines[i] for the federal
government. Exactly what status the word “must” has in that context is
debatable).
However, if we can now step into
the real world, let me ask how many readers are currently receiving SBOMs from
even one of their software or intelligent device suppliers, which list every
one of the “first level” components (I put that phrase in quotes, since
technically there’s no such thing as levels in an SBOM, but in practice
everybody talks about them, including me)? And, even if the supplier swears on
a stack of Bibles that every first-level component is listed, are you sure they’re
telling the truth?
I didn’t think I’d see any hands,
although I’ll point out that’s a trick question. After all, how many users are
going to audit their suppliers to make sure they’re including all the “first-level”
components in an SBOM? That’s right, nobody is – nor would it make any sense to
do that. The only way you could audit the supplier would be to ask them to produce
another SBOM – and then you’d have to audit that one, and then…turtles, all the
way down.
But the biggest problem with this suggestion
(or whatever it is), is that it’s likely to prevent many suppliers from
producing SBOMs for their customers at all. After all there are some perfectly
good reasons why the suppliers won’t be able to “comply” with this suggestion. Perhaps
the three most important are:
First, the contents of the SBOM –
including the number and identities of components - will vary depending on when
the SBOM is produced: whether it comes from the source code, whether it was
created during the build process, whether it was created with the final build,
whether it was developed from the actual binary files distributed with the
software, etc.
Because components are added,
replaced or removed at each stage – and since the components in the SBOM on one
day will often be different from the components you’d find the next day, if the
software were still being built – the only way the suggestion could possibly
have any rigorous (i.e. auditable) meaning would be if it specified exactly the
circumstances under which the SBOM was created. And, if there were some way to
come back and recreate those exact circumstances later during an audit, which
of course there isn’t.
Second, components are notoriously
hard to identify with any certainty, because of the naming
problem. For vulnerability management purposes, it does the software user
no good to learn that a component is found in a product they use, but at the
same time not know of an identifier with which they can find that component in
a vulnerability database like the NVD.
If the supplier decides to leave
that component out of the SBOM (or more correctly, leave it in, but just enter “NOASSERTION”
for each field describing the component. NOASSERTION is the SPDX term meaning “I
have nothing to say about this field for this component”. In CycloneDX, it’s just
a blank line), IMO that is perfectly understandable, and shouldn’t be held
against them.
Finally, there are some suppliers
(I know auto industry suppliers are a good example of this) who regard the identities
of some components (even open source components) in their products as their IP,
which would be jeopardized if they revealed it.
Are they correct in holding this
belief? Who knows, other than the suppliers themselves? But here’s the punch line: Would you rather receive
“incomplete” SBOMs from a few suppliers or receive exactly what you’re
receiving currently - zero SBOMs from zero suppliers? If you prefer the latter,
then I recommend you put ironclad language in your contracts requiring complete
SBOMs, as described in the Minimum Elements. And give yourself the
title, “Director of SBOM Prevention”.
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]
From the Executive Summary: “…this report defines the scope of how to think
about minimum elements…” This doesn’t sound like “must” to me. How about you?
No comments:
Post a Comment