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.
Do no damage
By providing an SBOM to legitimate users of software while limiting potential attackers' access to this information provides all of the benefits that an SBOM is meant to provide while removing one of the important security issues that having them freely available would cause.
And the damage done by having SBOMs public could be significant. Consider a case that’s a simplified version of what we see everywhere in the real world: Application A depends on Application B, which in turn depends on Application C, which in turn depends on Application D. Now, what happens if an exploitable vulnerability is found in Application D? Even if the engineers that maintain Application D are very hard-working and diligent, it might take them a few days to create and test a patch for this new vulnerability. Once that is deployed, the equally hard-working and diligent people working on Application C will need at least a few days to test this patch on their product. Once the patched version of Application C is released, the people working on Application B get their turn, etc.
Each step of this process can take at least a few days, and the total time that it takes for the fully patched version of Application A to be available can be quite a while: at least several days. Now, if we are advertising to the world exactly what the dependencies are on Application D, clever hackers will be able to note this and develop exploit code for Application A well before the security issue can be addressed in it. So by telling hackers exactly what they can exploit, we are essentially telling hackers, "Here’s a place where you have a couple of weeks to exploit this weakness before it will be patched." That’s probably a bad idea.
And note that an SBOM is currently information that can legitimately be protected as a trade secret. By requiring that an SBOM be made publicly available, the government would be put in the difficult position of depriving software businesses of intellectual property that they currently own. This may raise difficult legal issues.
And while there are clearly cases where the government’s interest is compelling enough to justify depriving businesses of certain intellectual property, it is unlikely that such a compelling case exists with SBOMs. As noted above, providing this information under NDA to authorized users of software provides all of the benefits that an SBOM is meant to provide while minimizing the trouble that the availability of an SBOM could cause.
No utopia here
The days of thinking that some sort of utopian future will be greatly enabled by the ability to freely use information to enhance or modify any software that you are using are probably in the past. It’s likely that in the future this type of thinking will look as quaint as the vision of the Internet described in John Perry Barlow’s “A Declaration of the Independence of Cyberspace.” If you’ve forgotten this, here’s how it begins:
"Governments of the Industrial World, you weary giants of flesh and steel, I come from Cyberspace, the new home of Mind. On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You have no sovereignty where we gather."
That didn’t happen, did it? Instead, the Internet became a part of the critical infrastructure of national governments, and lots of regulation accompanied that. It certainly looks like software is similarly a part of the critical infrastructure of national governments, so we should expect them to start regulating its development and use.
There are lots of reasons why this might be a good idea, and there are lots of good ideas around about how this could be done in a good way. But requiring an SBOM to be public isn’t one of them.
No Security is a monthly column.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
