Monday, April 4, 2022

Finally, guidelines for using SBOMs!


It’s no exaggeration to say that almost the entire focus of the SBOM literature so far has been on production of SBOMs: that is, describing what software suppliers need to know in order to produce usable SBOMs, including of course a lot of discussion of formats.

This is in retrospect not too surprising, since when the NTIA Software Component Transparency Initiative started in 2018, there wasn’t much awareness of SBOMs among either software suppliers or software users. Today, in large part due to the good work of the Initiative (which ended last year) and the documents they produced, suppliers are both aware of and using SBOMs; that trend will continue.

However, suppliers are producing SBOMs almost exclusively for their own use. That is, they’re producing them so they can be aware of cybersecurity risks to the products they develop, which are due to the components they include in their products. The supplier needs to learn about the level of risk posed by each component in the product in order to determine, for example, whether a component has any serious unpatched vulnerabilities that warrant removing the component and replacing it with a less risky one. Having SBOMs for their products is important for a supplier in achieving that goal.

Of course, it’s a good thing that suppliers are making use of their own SBOMs. It means that the software we all use is becoming less risky. But SBOMs have been touted all along (including in this blog, to be sure) as a way for end user organizations to learn about the risks posed by components in the software they use. To do that, those organizations (i.e., any organization, private sector or governmental, that uses software) need to receive SBOMs from their software (and intelligent device) suppliers. Except in rare cases, that simply isn’t happening now.

Why aren’t the users receiving SBOMs from their suppliers? As I just said, it’s likely that most larger suppliers have SBOMs for their products now; and if they don’t, it’s almost trivially easy for them to start producing them. In fact, given the advantages of having SBOMs for their own use now, you have to wonder about any supplier who tells you they don’t have them today.

The reason why suppliers aren’t distributing SBOMs is that their customers aren’t asking for them. So why aren’t the customers asking for them? Now we’re getting to the heart of the problem. There are two important things that users need, which they don’t have now.

The first thing users lack is one I’ve mentioned before: low-cost or open source automated tools or third-party services, that will ingest SBOMs (and VEX documents) provided by software suppliers. Those tools or services will then produce for the user organization a list of exploitable vulnerabilities that are due to components included in the software they employ to run their business. There is some progress being made addressing this problem, but I’ll admit it’s coming slowly – far too slowly for a lot of our tastes.

But the second thing is just as important as the first: users need documentation that provides a coherent narrative (at a high level, of course) of all the steps they need to take in order to use SBOMs and VEX documents to mitigate their software supply chain cyber risks. More importantly, the documentation needs to be written for a software user that doesn’t already have a good understanding of software development and SBOMs.

This latter point is especially important. During its three years of existence, the NTIA Initiative produced good documents about SBOMs, some of which touched on how they should be used. But all of those were written from the point of view of software developers (suppliers). And they mostly use language that developers understand, which is foreign to a lot of end users. This isn’t surprising, since the great majority of participants in the meetings were either developers or consultants to developers.

This is why I’m quite pleased to announce that there’s now a document available that provides a comprehensive narrative of what an end user organization needs to do to obtain SBOMs and VEX documents and use them for the purpose of reducing the cybersecurity risks their organization faces – specifically risks due to components found in the software they utilize to achieve their mission. Fortress Information Security[i] has just released a white paper titled “Software Bills of Materials Consumer Use Cases”. It’s available here.[ii]

Two caveats about this paper:

1.       While the paper provides a good picture of how SBOMs can be obtained and used now, this is still early in the SBOM “game” and there are bound to be lots of changes over the coming few years. I hope Fortress will update the document regularly.

2.       Even based just on what’s understood today, there is undoubtedly a lot more that could be added to this paper – for example, regarding VEX documents. So there might well be further white papers addressing specific topics on the consumption spectrum.

I hope you’ll enjoy the paper! If you have comments or questions about it, please drop them to tturner@fortressinfosec.com – and if you don’t mind copying me, I’d love to see them as well.

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] Full disclosure: I have been consulting with Fortress for over two years. I contributed some ideas for the paper, but I wasn’t one of the authors. 

[ii] You’ll have to fill out a short form before downloading the white paper. A small price to pay!

No comments:

Post a Comment