Thursday, January 26, 2023

“NOASSERTION”? No problem!

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