An SBOM is Not Enough—You Also Need Context
In a previous post, we discussed whether a Software Bill of Materials (SBOM) can really make a difference from a cybersecurity standpoint, and the answer is a resounding “yes.”
However, while an SBOM provides lots of the information organizations need to know about the components of the software products they buy and use, such a list by itself is not enough. For the SBOM to be really effective, they need to have context as well.
Not all software products or vulnerabilities are equal. And depending on the situation, they will have a range of impacts—or no impacts at all—on the organizations using the products.
Using The Vulnerability Exploitability eXchange (VEX) With An SBOM
To gain an understanding of how context applies to the SBOM, consider the Vulnerability Exploitability eXchange (VEX) developed as part of the National Telecommunications and Information Administration (NTIA) Multistakeholder Process for Software Component Transparency. The VEX concept was developed to fill a particular need regarding the use of SBOMs, NTIA says, although VEX is not limited to use with SBOMs or necessarily expected to be included in the SBOM itself.
NTIA, an agency of the U.S. Department of Commerce, says the primary use cases for VEX are to provide software users (operators, developers, services providers, and others) with additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate.
“In many cases, a vulnerability in an upstream component will not be ‘exploitable’ in the final product for various reasons,” NTIA says. For example, the affected code might not be loaded by the compiler, or some inline protections might exist elsewhere in the software.
To reduce the effort expended by software users on investigating non-exploitable vulnerabilities that don’t affect a software product, suppliers can issue a VEX, the agency says. A VEX is an assertion about the status of a vulnerability in specific products.
The status can be: Not affected, so no remediation is needed regarding the vulnerability; affected, so actions are recommended to remediate or address the vulnerability; fixed, meaning product versions are available that contain a fix for the vulnerability; and under investigation, where it’s not yet known whether product versions are affected by the vulnerability.
While software suppliers could notify users of a non-exploitable vulnerability by email or any other means, NTIA says, a VEX is machine-readable. This enables automation and supports integration into broader tooling and processes. “Users can integrate component data from SBOMs with vulnerability status information from VEXes to provide an up-to-date view of the status of vulnerabilities,” the agency says.
This will likely enable users to take a much more targeted approach to finding and remediating vulnerabilities in their software. “A single VEX can convey information about more than one vulnerability in a product, or in multiple products,” the agency says. “VEXes will be published by the software supplier, but can also be authored by third parties.”
Concepts such as VEX are providing the needed context that gives SBOMs much more value for organizations looking to enhance software security.
