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

[Benjamin Robin <benjamin.robin@bootlin.com>]

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.

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com