The fallout of the SolarWinds cybersecurity incident, coupled with Cybersecurity Executive Order (EO) put the topic of software supply chain security, and by association, software bills of material (SBOM) center stage in the security dialog. Coupled with the Log4j vulnerability and impact that left countless organizations scrambling to determine the impact, SBOMs are now a critical component of modern cybersecurity vulnerability programs.
Among the benefits of SBOMs, which are essentially a list of components that make up a piece of software, is to identify potentially vulnerable components. Leading SBOM platforms and tools such as Dependency Track do this by tying vulnerabilities associated with components to the attention of those using the SBOM to analyze their software components. Dependency Track and other tools facilitate this process by querying sources such as the National Vulnerability Database (NVD), Sonatype OSS Index, VulnDB or OSV.
However, just because a vulnerability is associated with a component in software does not mean that the component is exploitable. This is where the Vulnerability Exploitability eXchange (VEX) comes into play.
What is the Vulnerability Exploitability eXchange (VEX)?
As defined by guidance from the U.S. National Telecommunications and Information Administration (NTIA), VEX’s primary use case is “to provide users (e.g., operators, developers, and services providers) 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.”
This is a lengthy way of saying VEX adds context to vulnerabilities to inform risk management activities. Much like other leading SBOM and software supply chain transparency and security guidance, VEX was born out of the NTIA’s Multistakeholder Process for Software Component Transparency. The guidance states that while VEX was developed for a specific SBOM use case, it isn’t limited to use with SBOMs or necessarily required, either.
Again, just because a vulnerability is present does not mean it is exploitable. This is critical information to know because with vulnerability management programs and activities, organizations are performing risk management. In cybersecurity risk management, organizations are looking to identify, analyze, evaluate and address cybersecurity threats based on the organization’s risk tolerance. This leads to the organization prioritizing risks based on likelihood and the severity of the risk materializing. Without knowing if a vulnerability is exploitable, it would be impossible to accurately project its likelihood.
How VEX adds context and clarity
How does VEX solve this challenge? It empowers software suppliers to issue a VEX, which is an assertion about the status of a vulnerability in a specific product. VEX supports four primary status options:
- Not affected: No remediation is required regarding this vulnerability.
- Affected: Actions are recommended to remediate or address this vulnerability.
- Fixed: These product versions contain a fix for the vulnerability.
- Under investigation: It is not yet known whether these product versions are affected by the vulnerability. An update will be provided in a later release.
With the SBOM itself as an example, we’re seeing a push toward machine-readable artifacts and documentation, which enables better automation, accuracy and speed. We’re seeing similar trends in the realm of compliance with NIST’s Open Security Controls Assessment Language (OSCAL), which brings traditional paper-based security controls and authorization documents into a machine-readable format.
VEX is doing something similar, avoiding the need to email security advisories or details about vulnerabilities and recommendations, and instead bringing that information into a machine-readable format to foster automation and the use of modernized security tooling that moves at a pace much closer to the current thread landscape than humans and manual activities. As the push for software supply chain transparency and security evolve, it isn’t hard to imagine a world where enterprise software inventories are able to be visualized in dashboards and tooling, along with their associated vulnerabilities and the actual exploitability of the vulnerabilities, all empowered by SBOM’s and accompanying VEX data.
That’s a stark contrast to the modern ecosystem where most organizations don’t have accurate inventories of the software components they consume and have deployed, nor the vulnerabilities associated with it. This is all despite the reality that modern software is overwhelmingly composed of open-source software (OSS) components, with some estimates reaching as high as 80% to 90%.
The guidance also states that while VEXs can be authored by a software supplier, they can also be authored by third parties, leaving users in a position to determine how to use the data. This makes it easy to see scenarios where security researchers and vulnerability vendors may make attempts to produce VEXs for products as part of their own product offering.
VEX resources
The SBOM initiative moved from NTIA to the U.S. Cybersecurity Infrastructure Security Agency (CISA), coinciding with a move of SBOM evangelist and leader Dr. Allan Friedman. In 2022 CISA has published two additional VEX documents. One is the VEX Use Cases document and the other is the VEX Status Justifications document.
The VEX Use Cases document provides minimum data elements of a VEX document, much like NTIA defined the minimum elements for an SBOM (as tied to the cyber EO). In this guidance, it states that a VEX document must include the VEX metadata, product details, vulnerability details and product status. These product status details include status information about the vulnerability in a product and can be not affected, affected, fixed or under investigation.
The VEX Status Justifications document subsequently focuses on the requirement for VEX documents to contain a justification statement on why the VEX document creator chose to assert that the product’s status is not affected, if they indeed did make that choice. This allows suppliers to provide justifications for why a product is not affected by a vulnerability. Options include the component or vulnerable code not being present, the vulnerable code not being able to be controlled by an adversary or the code not being in the execution path, and lastly the existence of inline mitigations already being in place in the product.
VEX represents a key next step in assisting SBOMs become actionable by providing contextual insights and assertions from product vendors about the exploitability of vulnerabilities present in their products. By using both the minimum elements as defined for VEX documents and their associated not affected justification fields, if applicable, software producers are able to empower software consumers for make risk informed decisions to drive their vulnerability management activities as part of broader cybersecurity programs.
Copyright © 2022 IDG Communications, Inc.
