On Fri, Feb 6, 2026 at 10:22 AM Mark Hatle <[email protected]> wrote: > > All of these improvements sound like a really good idea to me. > > I'm definitely on board with an image and build SPDX. They both have value, > and > I know for my own purposes I often compare what is in an image to a build > looking for things that could have been missed (such as static linking).
Just to be clear: There is now difference today between an "build" SBoM and and "image" SBoM. All SBoMs we produce include both. I don't want to produce multiple different types of (final) SBoM documents; it's just much easier for use to produce a single SBoM file and let users slice it up later then have to work about inter-document linkages (see our SPDX 2.2 output for why :). I'm more than happy to guide people on how to write tools to do that. > > (There are ways we can identify static linking with dwarf debug symbols. Some > work has been done on this in the past, but I also know we do our best to > avoid > static linking so it's not really progressed very far. If we do know of > places > where there is static linking that is NOT be identified in another way, it > might > be reason to finally spend some effort on that work again.) We can actually do this, but it is maybe not as direct as you might expect. If you set SPDX_INCLUDE_SOURCES = "1" the SPDX code will include all source files in the output SPDX. If you do this, the code will check output binary debug symbols, and cross reference the files listed from all build time dependency source files (which is why SPDX_INCLUDE_SOURCES must be set). Normally, the build_Build only does `hasInputs` on source files from the recipe itself, but when it does this it can end up referencing input files from other recipes as well. The practical output of this is that if a package uses a static library, the build that produces that package will `hasInput` on the sources of that static library (of note, this conveniently should also works for source libraries). It would be nice to also make another link (maybe `contains`?) that directly links the binary to the static library binary, but this takes extra steps since you need to cross reference source files to the correct static library binary, which is non trivial. > > --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 (#230642): https://lists.openembedded.org/g/openembedded-core/message/230642 Mute This Topic: https://lists.openembedded.org/mt/117675133/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
