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