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 [email protected]. 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#234343): https://lists.openembedded.org/g/openembedded-core/message/234343 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]] -=-=-=-=-=-=-=-=-=-=-=-
