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

[stondo@gmail.com]

From: Stefano Tondo <stefano.tondo.ext@siemens.com>

Hi all,

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.


Motivation
----------

The OpenVEX specification [2] is gaining adoption as the standard VEX
transport format. Several widely-used tools already consume OpenVEX
natively:

  - Grype (Anchore):       grype --vex openvex.json
  - Trivy (Aqua Security): trivy image --vex openvex.json
  - cosign/sigstore:       VEX attestation support

Having standalone OpenVEX files alongside SPDX SBOMs would enable:

  - Direct integration with the scanning tools listed above
  - Separate distribution of VEX data without shipping the full SBOM
  - Compliance with EU Cyber Resilience Act and US Executive Order 14028
    requirements for machine-readable vulnerability assessments
  - Decoupled VEX lifecycle: documents can be updated independently
    when vulnerability status changes

This implementation does NOT replace or conflict with the existing VEX
mechanisms. It is an additional optional output format that reuses the
VEX data already produced by Joshua's recipe-level SPDX architecture.


Implementation
--------------

The approach hooks into the existing create-spdx-3.0 workflow. When a
recipe has CVE data, the implementation reads the VEX assessment
relationships already present in the SPDX output and generates a
standalone .vex.json file in OpenVEX format alongside the SPDX
document. The SPDX VEX statuses (patched, unpatched, ignored, unknown)
are mapped to their OpenVEX equivalents, and product identification
uses PURLs from the SPDX packages. The feature is disabled by default
and opt-in via a single configuration variable.

The series is two patches (generation logic + selftests), both included
below for anyone who wants to look at the details.


Open questions
--------------

1. Should the OpenVEX document ID scheme use a different namespace
   than https://openvex.dev/docs/yocto/ ?

2. Is the SSTATE_ALLOW_OVERLAP_FILES += "${DEPLOY_DIR_SPDX}" approach
   acceptable for VEX file sharing between recipe and package sstate
   tasks?

Looking forward to your feedback.

[1] https://lists.openembedded.org/g/openembedded-core/message/213367
[2] https://openvex.dev/
[3] commit 6406240932 ("spdx30: Remove package VEX")
[4] https://patchwork.openembedded.org/project/oe-core/list/?series=&submitter=&state=&q=sbom-cve-check&archive=&delegate=

Stefano Tondo (2):
  spdx30: Add OpenVEX standalone document generation
  oeqa/selftest: Add tests for OpenVEX integration

 meta/classes/create-spdx-3.0.bbclass |  19 +++
 meta/classes/spdx-common.bbclass     |  15 +++
 meta/lib/oe/spdx30_tasks.py          | 193 +++++++++++++++++++++++++++
 meta/lib/oeqa/selftest/cases/spdx.py |  90 +++++++++++++
 4 files changed, 317 insertions(+)

-- 
2.53.0