From: Benjamin Robin <benjamin.robin@bootlin.com>
To: "stondo@gmail.com" <stondo@gmail.com>,
"Tondo, Stefano" <stefano.tondo.ext@siemens.com>,
"Freihofer, Adrian" <adrian.freihofer@siemens.com>
Cc: "openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>,
"ross.burton@arm.com" <ross.burton@arm.com>,
Joshua Watt <jpewhacker@gmail.com>,
Richard Purdie <richard.purdie@linuxfoundation.org>,
"marta.rybczynska@syslinbit.com" <marta.rybczynska@syslinbit.com>,
"Marko, Peter" <Peter.Marko@siemens.com>,
"mathieu.dubois-briand@bootlin.com"
<mathieu.dubois-briand@bootlin.com>
Subject: Re: [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation
Date: Wed, 01 Apr 2026 09:43:00 +0200 [thread overview]
Message-ID: <9600909.CDJkKcVGEf@brobin-bootlin> (raw)
In-Reply-To: <e37fc3654ebe48350a6f35a51792ac1be5d4c307.camel@siemens.com>
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,
--
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2026-04-01 7:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 14:19 [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation stondo
2026-03-31 14:19 ` [RFC PATCH 1/2] " stondo
2026-03-31 14:19 ` [RFC PATCH 2/2] oeqa/selftest: Add tests for OpenVEX integration stondo
2026-03-31 14:23 ` [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation Richard Purdie
2026-03-31 14:46 ` [OE-core] " Marta Rybczynska
2026-03-31 15:04 ` Joshua Watt
2026-03-31 22:05 ` Freihofer, Adrian
2026-04-01 7:43 ` Benjamin Robin [this message]
2026-04-01 9:58 ` Freihofer, Adrian
2026-04-01 11:34 ` Benjamin Robin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9600909.CDJkKcVGEf@brobin-bootlin \
--to=benjamin.robin@bootlin.com \
--cc=Peter.Marko@siemens.com \
--cc=adrian.freihofer@siemens.com \
--cc=jpewhacker@gmail.com \
--cc=marta.rybczynska@syslinbit.com \
--cc=mathieu.dubois-briand@bootlin.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
--cc=ross.burton@arm.com \
--cc=stefano.tondo.ext@siemens.com \
--cc=stondo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox