On Tue, Mar 31, 2026 at 4:23 PM Richard Purdie via lists.openembedded.org
<[email protected]> wrote:

> On Tue, 2026-03-31 at 16:19 +0200, [email protected] 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...
>
>
Useful VEX information includes vendor context (eg. checked that the
vulnerability
is not reachable under normal usage conditions). We do not have a framework
to
do so today. Necessarily, such VEX output will need to be manually edited by
vendors before publication.

Because of that, I agree with Richard that a standalone tool that extracts
the annotation
from SPDX and allows users to modify/add annotations is a better solution.

Kind regards,
Marta
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#234296): 
https://lists.openembedded.org/g/openembedded-core/message/234296
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to