On Tue, 2026-03-31 at 09:04 -0600, Joshua Watt wrote: > On Tue, Mar 31, 2026 at 8:23 AM Richard Purdie > <[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... > > Agreed. I already prototyped this here: > https://github.com/JPEWdev/spdx3toopenvex > feel free to use it as a > reference for how to do the conversion from SPDX 3 -> OpenVEX >
I agree that generating the SBOM and then processing it with independent, specialized tools is the right approach — and I believe that was also what I proposed, based on Ross's post in that earlier discussion. Taking this further, though, raises an interesting question: how could CVEs discovered after the SBOM/VEX was built with Bitbake be handled in a more automated way? A tool with access to the latest CVE database, an XL SBOM, and the corresponding source and debug packages could likely mark many CVEs as not_affected automatically — for instance, because certain source files are not compiled, or a relevant #ifdef is disabled. Would it make sense to extend sbom-cve-check to support exporting an OpenVEX document covering all CVEs at the time of execution? Such a tool would need to: * Download the CVE database * Extract static CVE status information from the SPDX document * Attempt to automatically evaluate the status of CVEs found in the database but not mentioned in the static SPDX This essentially describes merging Joshua's tool with Benjamin's sbom- cve-check into a unified tool that can ingest SPDX data, NIST information, source files, and more — and produce various outputs such as CVE check graphs, summary tables, and VEX documents in multiple variants. It's also worth asking how Yocto-specific such a tool would actually need to be. It could potentially be generic enough to support various Linux distributions — which leads to the question: does something like this already exist? Regards, Adrian > > > > > Cheers, > > > > Richard > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#234318): https://lists.openembedded.org/g/openembedded-core/message/234318 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]] -=-=-=-=-=-=-=-=-=-=-=-
