VEX in the trenches: how exploitability data actually flows

On paper, the VEX story is tidy: suppliers publish VEX documents alongside SBOMs declaring which vulnerabilities are actually exploitable, consumer tooling suppresses the false positives, and the noise melts away. (I'll open with a one-slide VEX primer, so no prior VEX experience is needed.)

Reality is messier. Very few vendors publish VEX at all; most exploitability decisions are born as triage clicks in a vulnerability-management tool and die there - they never become a document.

The few who publish can't agree on a channel: Red Hat ships CSAF files per CVE, Chainguard attaches OpenVEX attestations to container images, Apache Logging serves a CycloneDX VDR from its website. Three publishers, three formats, three delivery mechanisms - that is the state of the art.

Even when VEX arrives, there's a trust problem. Red Hat's file for the XZ backdoor (CVE-2024-3094) declared 26 products not_affected, every one justified as vulnerable_code_not_present. Will you auto-accept all 26 and silence your alerts?

This talk maps the VEX workflow as it actually exists:

• Origin: VEX is triage-first, document-second. Your analysts' not_affected decisions ARE your VEX; the document is an export format.

• Export: turning internal triage into a shippable VEX that rides with the release, so downstream consumers inherit your analysis instead of redoing it.

• Import - where the specs go quiet: a trust gate mapping issuer class (self / vendor / third-party) × claimed state to auto-accept, stage, or reject; scope-conflict resolution across org/component/branch/release levels via least-permissive demotion; and handling severity when CycloneDX omits it and OpenVEX has no field at all.

• The loop: imported VEX feeds your triage, which becomes the VEX you export - chains of trust across a multi-tier supply chain.

Live demo: we import a deliberately contradictory multi-statement CycloneDX VEX and watch the pipeline accept, stage, and reject statement by statement, with staged claims landing in a review inbox. Shown on ReARM, a FOSS (AGPL-3.0) release governance platform; the concepts are tool-agnostic.

Takeaway: a checklist of decisions to make before wiring VEX into CI, and what to actually ask your suppliers for.

Where exploitability decisions actually originate - triage-first, document-second; and how to export them so downstream consumers inherit your analysis.

A decision checklist before wiring VEX into CI: trust gates by issuer class, scope-conflict resolution, severity reconciliation.

Concrete asks for your suppliers: which format, which channel, which justifications.

A browsable FOSS implementation of VEX import adjudication to study.