The idea of a software bill of materials (SBOM) is a hot topic these days. The National Institute for Standards and Technology (NIST) and the National Telecommunications and Information Administration (NTIA), both parts of the US Department of Commerce, have been organizing workshops, soliciting input from interested parties, and doing all of the other usual things that government agencies do before making a major ruling, at least when the outcome of the ruling isn’t dictated by politics instead of what actually makes sense.

Today, a definition of SBOM is conspicuously absent from NIST’s glossary of computer terms, which is very uncharacteristic of how NIST operates. Usually, it’s the definitive source for things like this. In the absence of that, here’s a definition of an SBOM from the NTIA’s “Framing Software Component Transparency: Establishing a Common Software Bill of Material (SBOM)” (PDF):

” An SBOM is effectively a nested inventory, a list of ingredients that make up software components. An SBOM identifies and lists software components, information about those components, and supply chain relationships between them.”

Creating and maintaining an SBOM certainly sounds like a good idea. If you have a list of all of the components that comprise the software that you use, it’s easy to track how much the steady stream of new vulnerabilities affects you. It’s not hard to imagine running software that queries a list of known CVEs and tells you in real time how much each of the applications that you are running is vulnerable. That would be very useful.

But as with almost everything related to software, doing that in a useful and meaningful way is much harder than it sounds. And some of the people involved in the conversation around SBOMs probably aren’t making this any easier.

Here’s what you need to know about the state of the rules being proposed.
Public SBOMs are problematic

In particular, we ought to be concerned about some of the points made in the discussions at the recent workshop on the topic that NIST recently hosted. In particular, we should be very concerned about the point of view that many workshop participants voiced that suggested than an SBOM should be publicly available information. This is probably a bad idea.

First, we should note that requiring vendors to provide an SBOM to businesses that license software is probably a good idea. Users of software should be provided with information about exactly what the software that they license comprises. To support this goal, NIST should provide ongoing support to existing SBOM standards activities, such as the Software Package Data Exchange (SPDX) project and the Software Identification (SWID) Tags that are currently defined by ISO/IEC 19770-2015.

These standards provide a good basis for creating the SBOMs that consumers of software need, and NIST should actively encourage their adoption by US federal agencies, with the goal of having the requirements defined by that process eventually be adopted by the commercial world.

But there is absolutely no reason for an SBOM to be made public, by which we mean available to people who have not licensed a particular software application or are in the process of evaluating such an application for possible purchase. Such information is routinely protected under nondisclosure agreements (NDAs), and it is entirely appropriate for an SBOM to receive the same level of protection.

To provide an SBOM to potential adversaries makes their job easier. As NIST noted in SP 800-115, Technical Guide to Information Security Testing and Assessment: A Security Life Cycle Approach, the first phase of an attack is the reconnaissance phase, in which attackers determine the exact nature and configuration of the system that they plan to attack.

This phase is also defined in the “Cyber Kill Chain” methodology that Lockheed Martin has defined. For attackers to proceed to later phases of an attack, they must first complete the reconnaissance phase, and denying them access to an SBOM makes their job more difficult. Note that this in no way means that legitimate users of software are denied this information. It just means that it is not freely available to potential attackers.