Friday, April 8, 2022

Who writes the SBOM rules? You do.


Next week, I’ll tape a podcast sponsored by an organization that provides product security services to software and intelligent device suppliers. One of the questions they’ll be asking me is, “How should product security teams prepare themselves for SBOMs and VEXes?” Those teams are often referred to as product security incident response teams, or PSIRTs for short.

This is an interesting question, because I just wrote a post about the need for guidelines for SBOM and VEX use for end users who aren’t software developers. I started the post by saying that plenty had already been written about SBOM use for developers (suppliers), so I wasn’t too worried about them.

However, with respect to use of SBOMs, software or device supplier staff members fall into two groups. The first group consists of the development people, who – as far as I know – understand SBOMs well now and already have practical experience with them. These are who I had in mind when I made the statement in the previous post. I think these people don’t need a lot of help on using SBOMs, since so much has already been written about that, and there are a lot of tools available for them.

But the second group consists of the PSIRT – a team of security people (not developers) who don’t do development, but instead work to make the product as secure as possible. Since the PSIRT’s needs are quite different from those of the developers, they really can’t be expected to have much knowledge of or experience with SBOMs (and certainly not with VEXes).

My first idea for how PSIRTS should prepare for SBOMs was “Pray”. However, while I’ve never denigrated the importance of prayer, I do believe that isn’t all that can be said about the subject. There are multiple things that PSIRTS can do to get ready for the new SBOM world (and keep in mind that federal agencies will be required to request SBOMs from their suppliers, starting in August). Most importantly, PSIRTs need to do what all software users (which is just about every organization, public or private, on the planet. I can’t speak for other planets at the current time) need to do.

I hope to write other posts on the topic of preparing to use SBOMs, but here is probably the most important thing that all software users, including PSIRTs, should do:

Have a little humility. I’ve read and heard statements by various people about SBOMs, that are simply way off the mark. They obviously have never bothered to study up on the subject, but that doesn’t stop them from spouting off as if they understand SBOMs very well.  So here’s a tip: If you think that SBOMs are so obvious that you, the great and powerful Oz, already know everything you need to know about them, I can guarantee you’re wrong – although there are enough other people like you that nobody may call you to account for your statements.

However, I’ll also admit that learning about SBOMs isn’t easy presently. The NTIA Software Component Transparency Initiative – which ran from 2018 through the end of 2021 – published some useful documents, all of which are available here. However, these documents are sometimes contradictory (partly due to the fact that they were written by different groups, sometimes in different years). More importantly, they don’t tell a single coherent story, that will provide someone new to the SBOM topic an in-depth introduction to it (on the NTIA site, there’s a good two-page document titled “SBOM at a Glance”, but it’s just that: a two-page introduction).

There will be a new initiative of some sort under CISA, where Dr. Allan Friedman, who led the NTIA Initiative, moved last summer. However, that hasn’t actually started yet (it hopefully will start in about a month), and more importantly it’s not clear whether it will be anything like the NTIA Initiative. The best thing about the latter was the fact that lots of players from the private sector were able to freely discuss their real-life experiences with SBOMs and shape the content of the documents that were produced.

However, because CISA (and probably most of the federal government) has to operate by much more hands-off rules with respect to the private sector than does the NTIA or the Department of Commerce in general, it's possible that discussion will be much more constrained under CISA. And in any case, because it will probably be 2023 before useful documents are produced by the CISA initiative (which currently doesn’t have a name, at least a publicly announced one), I certainly don’t advise waiting until those documents are available, assuming they appear at all. This is especially important because the deadline for federal agencies to start requiring SBOMs from their software and device suppliers is this August.

However, this might be a good thing, since a lot of people seem to believe that the federal government is “writing the rules” – or even writing regulations – for SBOMs, and that the NTIA documents were a kind of “first draft” of those rules. However, the fact is that the NTIA doesn’t write regulations, laws, guidelines, guidance, edicts, Papal encyclicals, fatwas, Talmudic teachings, or anything like that.

The NTIA facilitates meetings and online discussions in which private industry players work out voluntary guidelines that are necessary for a new technology to be realized in practice. A great example of this is DNS. NTIA didn’t invent DNS, but it provided the forum where telecom providers and the nascent ISP industry, as well as others, could discuss how the DNS idea (which was developed in the academic world) could be made to work in practice. NTIA was the first domain name registrar, and later outsourced that function to the IANA (which now administers DNS with a budget of $100 million. I once asked Dr. Friedman if his budget for the SBOM Initiative was anywhere near that figure, and he surprised me by answering no 😊).

I think we can all agree that DNS works very well. After all, when was the last time that, in order to reach your favorite web site (perhaps this blog?), you had to enter a 32-digit IPv6 address? It’s safe to say that the internet would still be about its size in say 1992, without DNS. Yet, where are the laws or regulations that make DNS work? There aren’t any. Virtually all internet users have implicitly agreed to follow the guidelines developed at the outset under the NTIA’s guidance (but not, to be sure, developed by the NTIA itself!). That’s all it takes.

The same thing will be true for SBOMS. The guidelines that will make SBOMs work on a large scale will be developed by private industry. The documents developed by the NTIA Initiative provided a good start toward those guidelines, but that’s all they are: a good start. A lot more needs to be done before they can be considered finished. My personal opinion is that private industry needs to pick up the ball and run with it from here on.

Fortunately, that is beginning to happen. As I discussed in my previous post, Fortress Information Security has produced an excellent document[i] that goes at least part of the way toward providing the end-to-end narrative of utilizing SBOMs that is required for SBOMs to become widely used (although I wish it were the only thing that’s required!).

Other documents will surely follow, from Fortress, from other private sector entities, and hopefully from CISA. I also hope that one or more forums will arise in the private sector, where various “players” in the “SBOM marketplace” will exchange ideas on how to remove the various obstacles that are currently inhibiting widespread adoption of SBOMs – just one of which is lack of comprehensive documentation for how SBOMs can be used to reduce an organization’s level of supply chain cybersecurity risk.

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] I have a consulting relationship with Fortress, and contributed some ideas to that document, although I wasn’t one of the authors.

No comments:

Post a Comment