The wrong way to promote SBOMs

On one of the mailing lists of the NTIA Software Transparency Initiative this week, this article was passed around and got a lot of attention. On the one hand, it’s the best summary of the (long-term) benefits of SBOMs that I’ve seen in the press so far (it was written by two people from MITRE Corporation, one of whom is a former Deputy Director of the NSA). The authors both firmly believe that having SBOMs widely available is important for national security. No argument from me on that.

On the other hand, there are right ways and wrong ways to promote something. The wrong way is to a) not do much research on the subject yet assume that the little you’ve read about it makes you an expert, and b) set huge expectations that SBOMs won’t possibly be able to deliver. Unfortunately, this is a textbook example of the wrong way to promote SBOMs.

Ironically, it doesn’t seem that the authors of the article even talked with a very respected member of MITRE’s own staff, who regularly participates in some NTIA meetings and the email discussions. Nor, for that matter, do they seem to have read any of the NTIA documents on SBOMs, or participated in any of the meetings. If they had, they wouldn’t have made the following mistakes:

First, they imply that SBOMs might have in some way alerted users to the SUNBURST malware in the SolarWinds Orion updates they were installing (or even better, alerted SolarWinds to the fact that the malware was present in all the updates they sent over a 2-3 month period). Actually, while the SolarWinds attack (along with others) shows that software supply chain security is without doubt the most important supply chain cybersecurity consideration now, the fact is that the super-sophisticated way in which the Russians conducted the attack (Microsoft thinks that up to 1,000 people were involved) couldn’t have been detected by SolarWinds (although the fact that the Russians were operating at will inside their network for 15 months is inexcusable). Even though the Russians in fact implanted a component (SUNBURST) in about seven builds of Orion, they did it in such a way that it would have never been included in an SBOM that was generated at the end of the build (which is when they’re usually generated nowadays).

Second, they speak of a “standard” for SBOMs coming this year. This is wrong in many ways:

1.      The NTIA doesn’t develop standards, mandatory or otherwise. They also don’t develop guidelines, best practices, fatwas, Papal Encyclicals, Executive Orders, or anything else. The purpose of the Software Transparency Initiative is to get software suppliers and users together to determine what would be the best way to remove barriers that are currently preventing implementation of SBOMs. The Initiative has decided that the best mechanism for figuring these things out is to conduct Proofs of Concept, in which software and suppliers and users in a particular industry collaborate to work out the different issues of production, distribution and use (and if you want to learn more about the upcoming Energy Proof of Concept for SBOMs, attend the webinar next week, and also email afriedman@ntia.doc.gov to be put on the mailing list).

2.      There is already a widely accepted format for SBOMs; in fact, there are three widely accepted formats: SPDX, CycloneDX and SWID. Moreover, MITRE (funny thing about that!) is rumored to be working on a fourth. There’s nothing wrong with having multiple accepted formats, since there is already a tool that does a good job of translating between the formats. In fact, I’ve already observed the SPDX format adopting innovations in CycloneDX and vice versa (both are open source projects, one conducted by the Linux Foundation and one under OWASP. The leaders of both projects are active participants in the NTIA Initiative. They certainly don’t view each other as competitors).

3.      The issues with SBOMs are really around questions like: How often should an SBOM be generated? How should components be named in the SBOM, so that users can use the names to identify vulnerabilities (this is the Naming Problem)? How can suppliers avoid being overwhelmed with support calls for component vulnerabilities that aren’t in fact exploitable in their product (the issue I discussed in this post)?

4.      Allan Friedman, who leads the Software Transparency Initiative for NTIA, has said several times that he’s had to talk a government agency (or two or three) out of the idea of making SBOMs mandatory in some way. The fact is that, with all these important questions still to be answered (and perhaps addressed in slightly different ways by different industries), there simply is no way there can be a standard for SBOMs in the near future. Perhaps in five years there will be enough agreement on the answers to these questions that a standard would be possible. But I think it will be closer to ten years before use of SBOMs is so widespread that there needs to be regulation of them.

Third, the authors overpromise what SBOMs will do, or at least when they will be able to do it. For example, they say “When a new hack is uncovered, cyber defenders can use these software manifests to identify precisely which systems in the U.S. government are vulnerable.” It will be at least ten years before SBOMs are widely accepted and used, to the point that it might be possible to talk about identifying systems that are affected by a new vulnerability “precisely”. Until then, when serious vulnerabilities in components are identified (such as the Ripple 20 vulnerabilities), we should be happy if we can identify some fraction of the systems affected by a particular component vulnerability. That fraction will undoubtedly grow over time, but it will never be 100%. But having maybe ten out of 100 systems protected is better than having 0 out of 100.

Here are the three major changes I would have suggested in the article:

1.      Get rid of the talk about a coming standard for SBOMs. That’s simply not true, and more importantly it will make some people get into a compliance mindset regarding SBOMs. They will conclude “If there’s a standard coming, I’ll certainly be given plenty of time to come into compliance with it. I’ll focus for the time being on the 20 other standards that I have to comply with now.” This mindset can literally hinder adoption, not promote it. The fact is that the case for SBOMs is very compelling, with or without regulation: The average software product has 135 components, although some products contain thousands of components. Just like the product itself (i.e. the code written by the company whose name is on the software) can develop vulnerabilities, each of those components can do the same. Without an SBOM, you’ll never know about those vulnerabilities, unless your supplier is willing to tell you (fortunately, a large portion of them are willing, but it’s nowhere near 100%. A 2017 study by Veracode said that only 52% of software suppliers even bother to patch component vulnerabilities, let alone tell their customers about them).

2.      Don’t talk about solving our problem in any absolute sense. And especially don’t say (as unfortunately the authors did) that “Software vulnerabilities have been with us for more than three decades, since the Morris Worm crippled internet servers in 1988. We cannot tolerate it (sic) any longer.” Guess what? SBOMs will never solve the problem of software vulnerabilities, just like cold medicine will never solve the problem of common colds. What they will do is provide visibility into what is without doubt the largest source of vulnerabilities in any modern software product: the third-party and open source components it’s made of.

3.      Start to learn about SBOMs (especially if you plan to write articles promoting them). Above, I provided links to the document page of the NTIA Software Transparency Initiative site, as well as information on the upcoming third in NTIA’s series of four webinars on SBOMs for the energy industry. And if you’d like to review videos of the first two webinars in that series, go here and here.

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.