“SBOM”—or “software bill of materials”—is one of the hottest new buzzwords in cybersecurity today, and for good reason. Each day brings new headlines about the latest supply chain attack, followed by a slew of security pundits with various ideas about how to protect that supply chain. In all of this, you will inevitably hear the concept of an SBOM offered up as a solution, but what are SBOMs, and how are they used?
Defining The SBOM
An SBOM is a lot like a packing label you might see when you get a physical product delivered. In its simplest form, an SBOM does the same: It lists the contents of the software that you received in your software product.
This is an important piece of information because every piece of software you use is part of a much larger supply chain. When developers write code, it’s common and expected that they will use software from other developers in the process.
We most often think of this other software in the form of “libraries”—pieces of reusable code that have already been written, tested and documented that speed up our own development work. In most cases, even those libraries use other libraries.
The role of the SBOM here is to take a deep dive into the supply chain and inventory all the libraries your software includes. They can be generated using specific tools if you have access to the source code. For other software, it’s usually up to the vendor to publish the SBOM, but most do not.
Security In SBOMs
Now that we have a list of the software in our supply chain, wouldn’t it be great if we could also see if there are security vulnerabilities in that chain? After all, it’s reasonable to assume that if there is a security issue with the software from a BOM, there is going to be some level of issue inherited in our final software.
That’s exactly what Vulnerability Exploitability eXchange—or VEX—is for.
Put simply, a VEX file is a document that accompanies your SBOM and adds information about any specific vulnerabilities with the software you are analyzing. By adding a VEX file to your SBOM process, you get a much deeper insight into the vulnerabilities in your software. If you were to have VEX data about your entire supply chain, you’d be able to analyze all known vulnerabilities in your software in a way that has never been possible before.
The Problem
If this all sounds a little too good to be true, that’s because right now, it is. Generating SBOMs—let alone generating a VEX file—is just not common practice yet. And if you had those documents today, would you really know how to use them?
There are a few service providers that are starting to get into the SBOM generation and analysis space that are worth searching on. However, it is important to understand not only that there are vulnerabilities but also the importance of those vulnerabilities and where they actually exist in your system.
Ultimately, we need vendors to start supplying this information—and they may have to soon with mandates from the FDA, Executive Order 14028 and various other recent rules and regulations.
Making Sense Of All Of This
As a long-time security professional, I understand how the addition of more buzzwords can seem to complicate what is already a complex space. With every new topic area, I find it very helpful to break down new problems like this into terms we already know.
In this case, an SBOM is simply a software inventory. Software inventory is not necessarily an easy task, but the reality of it is that an SBOM simply catalogs the software in your environment. There are always going to be issues with the discovery and management of assets, but this is nothing new to the seasoned IT and security professional.
As for VEX, this is just vulnerability management. While vulnerability management, too, is a very complex and nuanced topic, the fact is that security professionals are going to be collecting the same kinds of vulnerability data they currently manage—just more of it. The real challenge is determining what you should do when you discover these new vulnerabilities and just how much they affect you in your own environment.
To my fellow security professionals, keep doing what you’re doing and be prepared to remediate more vulnerabilities. To the software vendors—it’s not a matter of if; it’s a matter of when. Get ahead of the curve while you still can.