Solving the Vulnerable Software Mystery: How VEX Documents Save Time and Resources
Organizations appreciate and recognize the need for securing software more than ever. Software Bills of Materials (SBOMs) are a powerful asset for companies that produce and consume software because they provide visibility into the components that make up applications. With the transparency provided by SBOMs, teams across the organization are empowered to reduce business risk.
What happens when we learn that an open source component found in the SBOM of a product we have procured has known vulnerabilities? Until recently, software product suppliers haven’t had a standardized way to communicate to customers whether their products are actually affected by a vulnerability present in the software’s dependencies. The National Telecommunications and Information Administration (NTIA) has been helping to develop the Vulnerability Exploitability eXchange (VEX) document format to help provide clarity around how to communicate the impact of third-party software vulnerabilities in a software product. With a VEX, software product suppliers can communicate that a product affected by a vulnerability found in one of its components is classified as one of the following:
- Under research to determine whether the product is affected by the vulnerability found in the component in question
- Not affected by the vulnerability found in the component in question
- Affected by the vulnerability found in the component in question with no recommended remediation or patch activities yet
- Affected by the vulnerability found in the component in question with recommended remediation activities (often referred to as a security advisory)
For example, here’s a high-level, fictional example of how VEX information may improve clarity for software product consumers:
First, let’s say you are a consumer of ACME’s widget, which uses the foobar.js library. The National Vulnerability Database discloses a CVE-2021-9999, a critical severity vulnerability in the foobar.js library. ACME then investigates CVE-2021-9999 and finds that it does not impact their widget and they issue a VEX claiming that the widget is “not affected” and no action is required by their consumers. With visibility into SBOM data, vulnerability data, and VEX data as a consumer you can strategically remove focus from the unaffected widget.
In the absence of signals like those described above from a software product supplier, a consumer may take expensive, unnecessary action in an attempt to mitigate a vulnerability that ultimately presents little to no risk. With the volumes of vulnerabilities found in many large organizations today, any chance to prioritize vulnerability remediation activities that present greater opportunities to reduce real risk is welcome.
Large organizations’ vulnerability management teams should become familiar with the emerging VEX document concept so they are prepared to make use of them as they become more adopted by software product suppliers. Further, their procurement teams should consider informing software product suppliers that they will soon expect SBOMs for the products they procure and that if vulnerabilities are found in the product, a complimentary VEX document should be issued to help the organization filter out benign findings and highlight areas of confirmed weakness. While in its early stages today, VEX is gaining traction quickly and understanding how to adopt it in your software supply chain strategy may pay dividends in time and money.
