Revolutionizing Vulnerability Management with VEX

Tim Calotta
Jul 13, 2023
Revolutionizing Vulnerability Management with VEX

Learn how Replicated, in collaboration with Chainguard, will empower independent software vendors (ISVs) with enhanced vulnerability management through the introduction of a VEX feed for KOTS images. This change instills increased confidence in image security and hygiene for our software vendors and their enterprise customers, enabling them to deploy and manage applications with assurance.

The Challenge of Vulnerability Management

Think back to April 1, 2014. Despite being April Fools’ Day, it was no laughing matter when the Heartbleed vulnerability in OpenSSL was announced. Once the full scope of Heartbleed’s impact became clear, everyone was asking the same questions: Does our software use this? Do we run commercial software that uses this? Are we impacted? How do we fix this? Engineers were left scrambling to determine their exposure and manually find the necessary fixes. Frantic phone calls, emails, tweets, forum posts, support tickets, and more all flew as people searched for answers amongst disparate data sources. In the end, the full remediation effort for Heartbleed took months, despite a patched version of OpenSSL being released just six days later. This chaos highlights the communication and coordination challenges around vulnerability management.

What is VEX and How it Improves Software Security

Enter VEX, or Vulnerability Exploitability eXchange, a security advisory standard designed to tell users whether a product is impacted by a specific vulnerability and, if affected, how to fix it. VEX is machine-readable which enables automation and supports broader tooling and processes. When integrating component data from SBOMs (Software Bill of Materials) with vulnerability status information from VEXs, ISVs gain a current view of the status of vulnerabilities in their software. This standardized data feed eliminates the need for manually determining exposure and enables a targeted and automated approach to vulnerability remediation.

The Anatomy of a VEX

The root element of a VEX is a document, which contains metadata and VEX statements:

VEX Document including metadata, Vex Statements, vulnerability details, product details, and status.

Much of the VEX syntax is straightforward, although a few things are worth noting:

  1. A VEX can have many statements attached to it. A software supplier who makes many applications can use many VEX statements within a single VEX.
  2. The status of a vulnerability can be categorized as any of the following:
  • Not affected – No remediation is required regarding this vulnerability. 
  • Affected – Actions are recommended to remediate or address this vulnerability. 
  • Fixed – Represents that 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.

Pulling it all together

To illustrate the effectiveness of a VEX in communicating a vulnerability status, let’s revisit the Heartbleed incident on April 1, 2014. This time, imagine receiving a VEX from Canonical as an engineer at a software supplier:

Example VEX document of the Heartbleed incident detailing the statement, vulnerability, product id, and status

Vulnerability management is hard, but by leveraging VEX, engineers can assess the status of vulnerabilities without wasting resources on irrelevant information. Instead, they can spend their time focusing on securing their software. 

Learn More: