| Message ID | 20260331141956.608976-1-stondo@gmail.com |
|---|---|
| Headers | show |
| Series | spdx30: Add OpenVEX standalone document generation | expand |
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
On Tue, Mar 31, 2026 at 4:23 PM Richard Purdie via lists.openembedded.org <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote: > 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... > > 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
On Tue, Mar 31, 2026 at 8:23 AM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > 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... 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 > > Cheers, > > Richard >
On Tue, 2026-03-31 at 09:04 -0600, Joshua Watt wrote: > On Tue, Mar 31, 2026 at 8:23 AM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > 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... > > 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 > >
Hello, On Wednesday, April 1, 2026 at 12:05 AM, Freihofer, Adrian wrote: > 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? I’m not sure I fully understand the question. This is exactly the purpose of `sbom-cve-check`. It can be executed automatically from Yocto post-build, or at any time later outside of Yocto. > 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. `sbom-cve-check` is designed to do precisely this, or at least that is the goal. However, supporting `#ifdef` is not planned in the short term; filtering is currently done by filename. Unfortunately, not many CVE entries contain the information needed to automatically mark them as not affected. Only the kernel typically has this information properly filled in. > 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 I’m not sure I follow what you mean, this is exactly what `sbom-cve-check` is already trying to do. It can generate OpenVEX files. Perhaps not everything is perfect yet (far from it), and some parts may still need improvement. > 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. `sbom-cve-check` can generate multiple export formats and can be extended to support additional formats. > 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? The goal of `sbom-cve-check` is not to be tied to Yocto. As long as you can provide an SBOM in a supported format, `sbom-cve-check` should work. That said, there is still a lot of development needed to fully achieve this goal. > > Regards, > Adrian Best regards,
On Wed, 2026-04-01 at 09:43 +0200, Benjamin Robin wrote: > [You don't often get email from benjamin.robin@bootlin.com. Learn why > this is important at https://aka.ms/LearnAboutSenderIdentification ] > > Hello, > > On Wednesday, April 1, 2026 at 12:05 AM, Freihofer, Adrian wrote: > > 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? > > I’m not sure I fully understand the question. This is exactly the > purpose > of `sbom-cve-check`. It can be executed automatically from Yocto > post-build, or at any time later outside of Yocto. I was not aware that sbom-cve-check can export the CVE status as OpenVEX. If so, this question is obsolete and sbom-cve-check already does what I'm proposing. :-) > > > 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. > > `sbom-cve-check` is designed to do precisely this, or at least that > is > the goal. However, supporting `#ifdef` is not planned in the short > term; > filtering is currently done by filename. > Unfortunately, not many CVE entries contain the information needed to > automatically mark them as not affected. Only the kernel typically > has > this information properly filled in. That sounds already very good. The kernel is by far the most relevant part which should be supported by this feature. Let's hope that other projects start adding the source lines to their CVEs in the future. Then it will become even more valuable. > > > 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 > > I’m not sure I follow what you mean, this is exactly what > `sbom-cve-check` is already trying to do. It can generate OpenVEX > files. > Perhaps not everything is perfect yet (far from it), and some parts > may > still need improvement. Having an initial version which defines this new architecture would already be a very big step! Thank you for driving this. > > > 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. > > `sbom-cve-check` can generate multiple export formats and can be > extended > to support additional formats. That leads then to the question about the purpose of the tool from Joshua. If I understand correctly it does something like e.g. sbom-cve-check --do-not-use-cve-db-just-filter-sbom could do, right? The code used for that would probably already be in the sbom-cve-check and probably have 99% overlap with the code from Joshua's tool. I'm just guessing and trying to understand where we could help. Thank you, Adrian > > > 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? > > The goal of `sbom-cve-check` is not to be tied to Yocto. As long as > you > can provide an SBOM in a supported format, `sbom-cve-check` should > work. > That said, there is still a lot of development needed to fully > achieve > this goal. > > > > > Regards, > > Adrian > > Best regards, > -- > Benjamin Robin, Bootlin > Embedded Linux and Kernel engineering >
On Wednesday, April 1, 2026 at 11:58 AM, Freihofer, Adrian wrote: > On Wed, 2026-04-01 at 09:43 +0200, Benjamin Robin wrote: > > [You don't often get email from benjamin.robin@bootlin.com. Learn why > > this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > Hello, > > > > On Wednesday, April 1, 2026 at 12:05 AM, Freihofer, Adrian wrote: > > > 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? > > > > I’m not sure I fully understand the question. This is exactly the > > purpose > > of `sbom-cve-check`. It can be executed automatically from Yocto > > post-build, or at any time later outside of Yocto. > > I was not aware that sbom-cve-check can export the CVE status as > OpenVEX. If so, this question is obsolete and sbom-cve-check already > does what I'm proposing. :-) Hum, sorry. I have no idea why I said that sbom-cve-check can export to OpenVEX. It can take has input (as annotation) an OpenVEX file. But currently there is no export to OpenVEX > > > 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. > > > > `sbom-cve-check` is designed to do precisely this, or at least that > > is > > the goal. However, supporting `#ifdef` is not planned in the short > > term; > > filtering is currently done by filename. > > Unfortunately, not many CVE entries contain the information needed to > > automatically mark them as not affected. Only the kernel typically > > has > > this information properly filled in. > > That sounds already very good. The kernel is by far the most relevant > part which should be supported by this feature. > Let's hope that other projects start adding the source lines to their > CVEs in the future. Then it will become even more valuable. > > > > > > 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 > > > > I’m not sure I follow what you mean, this is exactly what > > `sbom-cve-check` is already trying to do. It can generate OpenVEX > > files. > > Perhaps not everything is perfect yet (far from it), and some parts > > may > > still need improvement. Sorry see answer above. It cannot generate for now OpenVEX file. > Having an initial version which defines this new architecture would > already be a very big step! Thank you for driving this. > > > > > > 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. > > > > `sbom-cve-check` can generate multiple export formats and can be > > extended > > to support additional formats. > > That leads then to the question about the purpose of the tool from > Joshua. If I understand correctly it does something like e.g. > sbom-cve-check --do-not-use-cve-db-just-filter-sbom > could do, right? The code used for that would probably already be in > the sbom-cve-check and probably have 99% overlap with the code from > Joshua's tool. The command would be something like that: sbom-cve-check --ignore-default-config --sbom sbom.spdx.json \ --export-path openvex.json --export-type openvex But again there is no openvex export-type (Yet) > I'm just guessing and trying to understand where we could help. > > Thank you, > Adrian > > > > > > 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? > > > > The goal of `sbom-cve-check` is not to be tied to Yocto. As long as > > you > > can provide an SBOM in a supported format, `sbom-cve-check` should > > work. > > That said, there is still a lot of development needed to fully > > achieve > > this goal.
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(+)