Hi, I spent a little time this week comparing our cve-check with Bootlin’s sbom-cve-check[1].
tl;dr: has promise, needs a little further work. I think we can swap cve-check for sbom-cve-check in the LTS if we hurry. The background to this is that the existing cve-check class has some known limitations: - Uses the FKIE fork of the NVD database as a source of CVE data, which does not have the level of metadata it used to have - Only can be ran as part of a bitbake run, no way to do repeat scans a month later without involving bitbake Whereas sbom-cve-check is: (1) an independent tool, (2) scanning a SPDX manifest, (2) using both the FKIE/NVD database and the CVE Project cvelist. To elaborate on those points: 1) As an independent tool it can be ran at build time (potentially using meta-sbom-cve-check[2], or by calling the tool directly), or at any point in time after the build using just archived metadata to check for new issues. This is very useful for manufacturers who want to scan for issues routinely without having to do builds. 2) Whereas cve-check scans for CVEs at build-time in a recipe task and will (badly) generate aggregate reports for images, sbom-cve-check uses the image SPDX to know what products to look for issues in. This means it _only_ supports the “what issues does my image have” use-case and not “what issues are on my build machine” (eg issues in native tools). 3) The use of two different databases means it has more scope for improved metadata. It currently supports the FKIE mirror of the NVD data, the CVE List by the CVE Project (which is gaining improved metadata via their Enrichment Program), and further sources would be simple to add. As a test I did a build of core-image-sato and generated a report using both cve-check and sbom-cve-check. The differences were interesting. cve-check produced this report for the whole build: WARNING: avahi-0.8-r0 do_cve_check: Found unpatched CVE (CVE-2025-59529 CVE-2025-68468 CVE-2025-68471) WARNING: busybox-1.37.0-r0 do_cve_check: Found unpatched CVE (CVE-2025-60876) WARNING: expat-2.7.3-r0 do_cve_check: Found unpatched CVE (CVE-2025-66382 CVE-2026-24515) WARNING: expat-native-2.7.3-r0 do_cve_check: Found unpatched CVE (CVE-2025-66382 CVE-2026-24515) WARNING: ffmpeg-8.0.1-r0 do_cve_check: Found unpatched CVE (CVE-2023-51791 CVE-2023-51793 CVE-2023-51794 CVE-2023-51795 CVE-2023-51796 CVE-2023-51797 CVE-2023-51798 CVE-2025-22921 CVE-2025-25468 CVE-2025-25469) WARNING: glibc-2.42+git-r1 do_cve_check: Found unpatched CVE (CVE-2010-4756) WARNING: libpam-1.7.1-r0 do_cve_check: Found unpatched CVE (CVE-2024-10041) WARNING: libsndfile1-1.2.2-r0 do_cve_check: Found unpatched CVE (CVE-2024-50613 CVE-2025-52194 CVE-2025-56226) WARNING: linux-yocto-6.18.6+git-r0 do_cve_check: Found unpatched CVE (CVE-2008-4609 CVE-2010-4563 CVE-2019-14899 CVE-2021-3714 CVE-2021-3864 CVE-2022-0400 CVE-2022-1247 CVE-2022-38096 CVE-2022-4543 CVE-2023-3397 CVE-2023-3640 CVE-2023-39176 CVE-2023-39179 CVE-2023-39180 CVE-2023-4010 CVE-2023-6238 CVE-2023-6240 CVE-2023-6535) WARNING: polkit-127-r0 do_cve_check: Found unpatched CVE (CVE-2016-2568) WARNING: qemu-native-10.2.0-r0 do_cve_check: Found unpatched CVE (CVE-2019-12067 CVE-2021-20255 CVE-2024-6519) WARNING: qemu-system-native-10.2.0-r0 do_cve_check: Found unpatched CVE (CVE-2019-12067 CVE-2021-20255 CVE-2024-6519) WARNING: vim-9.1.1683-r0 do_cve_check: Found unpatched CVE (CVE-2025-66476) Aside: cve-check’s per-image reporting appears to be slightly broken and claimed that my sato image included images from meta-oe, which it did not. The report above is the reporting that is logged during the build. After writing some tooling for textual summaries, sbom-cve-check produced a report that is similar. The recipe list has differences: vim and a handful of other are not listed; but previously unreported CVEs in busybox, cairo, expat, glib-networking, gnupg, libgcrypt, libsoup, libxml2, mpg123, perl, tar, and the kernel are added. The recipes that are not listed are either native tools (which, by definition, are not in the image) or recipes that are built for dependencies but do not end up in the this specific image. In this case, dosfstools-ptest RDEPENDS on xxd which is built by vim, but as dosfstools-ptest is not installed there is no need for xxd. A number of CVEs are added, for example CVE-2024-58251 is a CVE in busybox which is missing the machine-readable CPE in the NVD data[3] but the CVE List has been “enriched” and has machine-readable data[4]. I’ve not yet triaged every one to identify the reason for the addition, but I expect this is the main reason. A more interesting feature gap is where a recipe statically links to another recipe: in this case there is no SPDX package entry for the library, so issues in the library will not be reported. With cve-check, the build-report will cover this, but the image-report will not. To summarise [5] the pros and cons: + sbom-cve-check can run at any point after the build + has better data sources which report more issues - only scans the literal packages that are in a final image, so we don’t get coverage of native packages or static linkage I wonder if the easiest fix for this gap is to enhance the SPDX generation to not only generate an “image SPDX” but also a “build SPDX”, which is essentially an aggregation of every recipe’s SPDX that is present. A recursive execution of the SPDX generation task will mean this covers both any native tools and static libraries that are in the dependency graph, for maximal coverage. This gives a solution without needing to be more clever in the image SPDX generation, for example including packages for all of the build dependencies (be them native or target). If this is done then I think sbom-cve-check is at least at parity with cve-check, and in many ways far superior. This will allow us to merge the few recipes and class from meta-sbom-cve-check into core, and delete cve-check. Any thoughts? (looking at Josh and Benjamin primarily) Thanks, Ross [1] https://github.com/bootlin/sbom-cve-check [2] https://github.com/bootlin/meta-sbom-cve-check [3] https://nvd.nist.gov/vuln/detail/CVE-2024-58251 [4] https://www.cve.org/CVERecord?id=CVE-2024-58251 [5] At this point I’m realising I need to read The Art of Explanation by Ros Atkins...
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2232): https://lists.openembedded.org/g/openembedded-architecture/message/2232 Mute This Topic: https://lists.openembedded.org/mt/117638559/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
