Re: [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2026-03-31 at 16:19 +0200, stondo@gmail.com wrote:
> Back at the end of December 2025, I had a conversation with Adrian
> regarding OpenVEX. Following my SPDX 3.0 enhancement series that was
> merged recently [1], I would like to propose adding OpenVEX [2]
> standalone document generation to the SPDX 3.0 workflow.
> 
> 
> Context: current VEX landscape in oe-core
> -----------------------------------------
> 
> Yocto currently has three VEX-related mechanisms:
> 
> 1. SPDX embedded VEX (Joshua's recipe-level architecture in
>    create-spdx-3.0): VEX assessment relationships embedded inside SPDX
>    3.0 documents, controlled by SPDX_INCLUDE_VEX. This is the richest
>    VEX data source, now at recipe level after the package VEX
>    removal [3].
> 
> 2. vex.bbclass (Marta Rybczynska): A standalone do_generate_vex task
>    that produces per-recipe JSON files and a rootfs manifest in a custom
>    Yocto JSON format. Used for CVE reporting and consumed by external
>    analysis tools.
> 
> 3. sbom-cve-check (Benjamin Robin, under review [4]): Post-build CVE
>    analysis using an external tool that reads SPDX SBOMs + vex.bbclass
>    manifests, then re-exports enriched SPDX 3 data.
> 
> What is currently missing is output in the OpenVEX format (openvex.dev),
> which is a lightweight, interoperable JSON format adopted by an
> increasing number of vulnerability management tools.

vex.bbclass is about to be removed, which simplifies things a bit.

Is there any reason we can't have an external script which extracts the
vex data from the spdx?

My personal view is that it might better to support various
conversion/extraction tools rather than trying to output all the
formats someone might want directly...

Cheers,

Richard