On Tue, Feb 10, 2026 at 4:45 PM Mark Hatle <[email protected]> wrote: > > After doing some unrelated work, I think I need to point out something I think > has been missed in this discussion. > > Not all DEPLOYED content is in an image. deployed content can include > firmware > components built by the system as well. These ARE target packages, but they > may > involve raw data flashed directly to a QSPI/OSPI, copied into a magic memory > location, etc.
Yes this is a know limitation of our current SBoM generation: It only works for images. It's on the TODO list to fix this, but it's tricky because while images are well formed with a defined task workflow, "deployed" artifacts are the wild west in how they work (you don't even need to call the task "do_deploy"), so some thought needs to be done to figure out how to address that. > > So there MUST be a way to handle these situations as part of the SPDX, SBOM > and > CVE processing. (This appears to be a gap in the current implementation > today.) I'm not sure that it MUST be done as a prerequisite; AFAIK all the current CVE scanning we do is either 1) per image (see vex.bbclass and cve-check.bbclass) or per-recipe (without building anything, e.g. cve-check.bbclass). We will have the same functionality with this new system where you can either scan a filesystem image, or all recipes (without building) with the SPDX scanning code. I don't really want to say that we MUST fix the deployed artifacts problem to roll this out when that's not even a covered use case of the current implementation :) If you want to make sure you cover all your bases, I would recommend doing both types of scans, as the all-recipe CVE analysis should catch all CVEs (at the expense of more false positives since it can't do as much filtering as per-image SBoMs can). However, the ideal case would be once we do eventually solve the deployed artifact problem, sbom-cve-check won't need special logic to understand it since it's just more data in the SBoM. > > --Mark > > On 2/4/26 11:29 AM, Ross Burton via lists.openembedded.org wrote: > > 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 (#230940): https://lists.openembedded.org/g/openembedded-core/message/230940 Mute This Topic: https://lists.openembedded.org/mt/117748416/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
