From: Stefano Tondo <[email protected]>
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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#234291):
https://lists.openembedded.org/g/openembedded-core/message/234291
Mute This Topic: https://lists.openembedded.org/mt/118596970/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
