Re: [Openembedded-architecture] Comparing cve-check with sbom-cve-check

[Mark Hatle <mark.hatle@kernel.crashing.org>]

On 2/10/26 6:00 PM, Joshua Watt wrote:
> On Tue, Feb 10, 2026 at 4:45 PM Mark Hatle
> <mark.hatle@kernel.crashing.org> 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.)

MUST is there must be a way to do this, not that it is done for random external 
packages automatically.

I.e. if I deploy my qspi and it contains a binary blob, and u-boot.  I need a 
way to tell it a manifest of: "this binary blob", "u-boot" ... and then have it 
do the same thing it does for other images.

So I think it would be completely reasonable for a qspi recipe to include one or 
more CVE/License/SPDX/SBOM, fill out one or more variables as a list of things 
that are included into this item, and then have the same(similar) code produce 
the output that a regular image would.

I'm hoping this is as 'simple' as collecting a manifest and processing it, but I 
don't honestly know.

> 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.

Yes.

--Mark

>>
>> --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 (#2232): https://lists.openembedded.org/g/openembedded-architecture/message/2232
>>> Mute This Topic: https://lists.openembedded.org/mt/117638559/3616948
>>> Group Owner: openembedded-architecture+owner@lists.openembedded.org
>>> Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [mark.hatle@kernel.crashing.org]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>