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