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:
Much of the VEX syntax is straightforward, although a few things are worth noting:
- 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.
- 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:
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:
- See our RepliCon Q2 2023 session with Chainguard on “The Current State of Supply Chain Security”
- Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
- Vulnerability-Exploitability eXchange (VEX) – An Overview
- Vulnerability Exploitability eXchange (VEX) – Use Cases
- The OpenVEX project on Github