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.
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.
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 root element of a VEX is a document, which contains metadata and VEX statements:
Much of the VEX syntax is straightforward, although a few things are worth noting:
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:
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.