Comparing cve-check with sbom-cve-check

Comparing cve-check with sbom-cve-check

[Ross Burton]

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

Re: Comparing cve-check with sbom-cve-check

[Joshua Watt]

Yes, I agree this should be the strategy for handling CVEs. It would
also be really good to get this in before the LTS

I'm working on some changes to SPDX that I think will help with this.
Specifically, I'm adding "Package" objects to describe recipes. This
allows the recipes to be linked as build time dependencies
independently of the build provenance (which does the same thing, but
for builds). The data in the recipe package will contain only data
that can be statically determined without actually building the
recipe, so it will give us the avenue to do CVE analysis without
actually building anything[1]. This should allow CVE analysis on the
native and static libraries since they will be included as build time
dependencies, even though they don't appear in the final image.


[1]: Sadly, it _can't_ include license information because
NO_GENERIC_LICENSE means you can have license text that you don't know
until after do_unpack; we should consider doing something about that.


On Wed, Feb 4, 2026 at 10:31 AM Ross Burton <Ross.Burton@arm.com> 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...

Re: Comparing cve-check with sbom-cve-check

[Benjamin ROBIN]

Hello,

On Thursday, February 5, 2026 at 12:54 AM, Joshua Watt wrote:
> Yes, I agree this should be the strategy for handling CVEs. It would
> also be really good to get this in before the LTS

Targeting Wrynose (around April 2026) is ambitious, but it might be feasible.

> I'm working on some changes to SPDX that I think will help with this.
> Specifically, I'm adding "Package" objects to describe recipes. This
> allows the recipes to be linked as build time dependencies
> independently of the build provenance (which does the same thing, but
> for builds). The data in the recipe package will contain only data
> that can be statically determined without actually building the
> recipe, so it will give us the avenue to do CVE analysis without
> actually building anything[1]. This should allow CVE analysis on the
> native and static libraries since they will be included as build time
> dependencies, even though they don't appear in the final image.

Thank you for working on this. I have a couple of requests:
 - It would be helpful to distinguish between native and target packages.
   The goal is to support a flag in `sbom-cve-check` that limits analysis to 
   packages deployed in the target (including static dependencies) or extends
   it to all components.
 - If possible (though not a priority), including layer information
   (URL, Git version, etc.) associated with a `build_Build` object would be
   valuable.
 
> [1]: Sadly, it _can't_ include license information because
> NO_GENERIC_LICENSE means you can have license text that you don't know
> until after do_unpack; we should consider doing something about that.
> 
> On Wed, Feb 4, 2026 at 10:31 AM Ross Burton <Ross.Burton@arm.com> wrote:

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

"Better" might be too strong, we support *more* data sources.
Sometimes, version ranges in the CVE List are incorrect, while the NVD 
database may provide more accurate information. However, users can configure 
their preferred data sources via a custom configuration file, so this isn’t a 
major concern from my perspective.

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

I agree with Joshua: improving the SPDX SBOM file is the right direction.

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

I concur, but we (Joshua?) need to tackle the SPDX generation improvements, 
which is no small task. On my end, I’ll update `sbom-cve-check` to handle 
these changes properly.

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: Comparing cve-check with sbom-cve-check

[Joshua Watt]

I think I have the SPDX changes that will be required _mostly_ ready
for you to look at:
https://git.openembedded.org/openembedded-core-contrib/log/?h=jpew/recipe-sbom

Run the command:
```
bitbake -c create_recipe_sbom meta-world-recipe-sbom
```
Which will make a complete recipe-level SBoM (names may change, since
"recipe" is a little confusing in this context) in
${DEPLOY_DIR_IMAGE}/meta-world-recipe-sbom-recipe-sbom.spdx.json

This SBoM uses new "recipe" packages that _should_ be sufficient to do
CVE analysis, but let me know if anything is missing; it also is
pretty quick to generate since it doesn't require doing a build.

On Thu, Feb 5, 2026 at 1:50 AM Benjamin ROBIN
<benjamin.robin@bootlin.com> wrote:
>
> Hello,
>
> On Thursday, February 5, 2026 at 12:54 AM, Joshua Watt wrote:
> > Yes, I agree this should be the strategy for handling CVEs. It would
> > also be really good to get this in before the LTS
>
> Targeting Wrynose (around April 2026) is ambitious, but it might be feasible.
>
> > I'm working on some changes to SPDX that I think will help with this.
> > Specifically, I'm adding "Package" objects to describe recipes. This
> > allows the recipes to be linked as build time dependencies
> > independently of the build provenance (which does the same thing, but
> > for builds). The data in the recipe package will contain only data
> > that can be statically determined without actually building the
> > recipe, so it will give us the avenue to do CVE analysis without
> > actually building anything[1]. This should allow CVE analysis on the
> > native and static libraries since they will be included as build time
> > dependencies, even though they don't appear in the final image.
>
> Thank you for working on this. I have a couple of requests:
>  - It would be helpful to distinguish between native and target packages.
>    The goal is to support a flag in `sbom-cve-check` that limits analysis to
>    packages deployed in the target (including static dependencies) or extends
>    it to all components.

We actually already track this for the SPDXDocument class as an
extension, since the native recipes need to handle a few things
differently. We could pretty easily add a similar extension to the new
recipe package that you could look at.

>  - If possible (though not a priority), including layer information
>    (URL, Git version, etc.) associated with a `build_Build` object would be
>    valuable.

We would like to do that and it's on the backlog. It's a little bit
tricky to get right, especially when dealing with multiple remotes in
the git repos, bbapends, etc. FWIW, our Yocto PURLs support this also,
we just don't have it implemented.

It also probably shouldn't be attached to the `build_Build`, but the
new "recipe" package (See below). I'm hoping you can now completely
ignore the build provenance information for CVE analysis now (unless
you want it to filter on source files or something). In fact, with the
new recipe packages, we could make the build provenance optional in
the SBoM output.

>
> > [1]: Sadly, it _can't_ include license information because
> > NO_GENERIC_LICENSE means you can have license text that you don't know
> > until after do_unpack; we should consider doing something about that.
> >
> > On Wed, Feb 4, 2026 at 10:31 AM Ross Burton <Ross.Burton@arm.com> wrote:
>
> > > 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
>
> "Better" might be too strong, we support *more* data sources.
> Sometimes, version ranges in the CVE List are incorrect, while the NVD
> database may provide more accurate information. However, users can configure
> their preferred data sources via a custom configuration file, so this isn’t a
> major concern from my perspective.

I think there is also a lot of value in a separate tool that can be
updated independently to deal with new sources using the same SPDX
data. For example, if we ever figure out a sane thing to do with PURLs
for vulnerability management, using e.g. OSV might be an option also
(esp. since the PURLs are already in the SPDX data).

>
> > > - 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).
>
> I agree with Joshua: improving the SPDX SBOM file is the right direction.
>
> > > 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.
>
> I concur, but we (Joshua?) need to tackle the SPDX generation improvements,
> which is no small task. On my end, I’ll update `sbom-cve-check` to handle
> these changes properly.
>
> --
> Benjamin Robin, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
>
>

Re: Comparing cve-check with sbom-cve-check

[Benjamin ROBIN]

Hello Joshua,

On Thursday, February 5, 2026 at 6:29 PM, Joshua Watt wrote:
> I think I have the SPDX changes that will be required _mostly_ ready
> for you to look at:
> git.openembedded.org/openembedded-core-contrib/log/?h=jpew/recipe-sbom

Thank you. I am currently evaluating your commits.

While being able to generate a SBOM for an entire layer is useful, the 
urgency, in my opinion, is to have a SBOM (the one that can be found in the 
deploy folder) with all the important information for a complete analysis:
- Elements (packages) "installed" on the target.
- And also build elements (what you have created: software_Package with
  software_SoftwarePurpose.specification).

Users are doing the build anyway; the generated SBOM associated with the build 
should contain "everything" for a proper CVE analysis. But I guess the commits 
that you have written are a first test, and it is not complete.

> Run the command:
> ```
> bitbake -c create_recipe_sbom meta-world-recipe-sbom
> ```
> Which will make a complete recipe-level SBoM (names may change, since
> "recipe" is a little confusing in this context) in
> ${DEPLOY_DIR_IMAGE}/meta-world-recipe-sbom-recipe-sbom.spdx.json

This is great; it will be very useful for a layer maintainer.

But on my side, I first tried a normal build with an empty build directory. 
The build failed around SPDX generation. For information I used the following 
KAS configuration:

-------------------
header:
  version: 18

build_system: openembedded
machine: qemuarm
distro: poky
target: core-image-minimal

repos:
  bitbake:
    url: https://git.openembedded.org/bitbake
    commit: af9dd012e7f4d16dccd1d6118be5da94ede68f85
    branch: master
    path: layers/bitbake
    layers:
      .: disabled

  openembedded-core:
    url: https://git.openembedded.org/openembedded-core-contrib
    #commit: 6ce19709f7835ee5cd7915e181f89397975236c8
    commit: 43737d14ab039c507a1a71177da68c7b41e4622f
    branch: jpew/recipe-sbom
    path: layers/openembedded-core
    layers:
      meta:

  meta-yocto:
    url: https://git.yoctoproject.org/meta-yocto
    commit: de4abc0a175af12eacc761a2e1e60ca7fdfeaa1b
    branch: master
    path: layers/meta-yocto
    layers:
      meta-poky:

  meta-openembedded:
    url: https://git.openembedded.org/meta-openembedded
    commit: 3787ecadbb198f56ac43025a15b3339c810c3a66
    branch: master-next
    path: layers/meta-openembedded
    layers:
      meta-oe:
      meta-python:
      meta-networking:

  meta-sbom-cve-check:
    url: https://github.com/bootlin/meta-sbom-cve-check.git
    commit: ea9fecee6073abab0f8d5d7ccb02077d1c6dc504
    branch: main
    path: layers/meta-sbom-cve-check

local_conf_header:
  cleanup: |
    INHERIT += "rm_work"
  spdx: |
    INHERIT += "vex"
-------------------

If I am using commit 6ce19709f7835ee5cd7915e181f89397975236c8 everything 
works, but static libraries are not listed (no associated package). But this 
is 
expected, since none of your changes were included.

If I try to switch to your commit (43737d14ab039c507a1a71177da68c7b41e4622f)
and run: bitbake -c create_recipe_sbom meta-world-recipe-sbom
I have the following errors (a lot of them) if I do not destroy the build 
directory:

ERROR: zlib-native-1.3.1-r0 do_create_recipe_spdx_setscene: Recipe zlib-native 
is trying to install files into a shared area when those files already exist. 
The files and the manifests listing them are:
  /work/build/tmp/deploy/spdx/3.0.1/x86_64/by-spdxid-hash/
70/706d8ec1deffb40c8b72ba34c22aaf543671078abd1a000c5fa0ee6f35274d2b.spdx.json
    (matched in manifest-x86_64-zlib-native.create_spdx)
  /work/build/tmp/deploy/spdx/3.0.1/x86_64/recipes/recipe-zlib-
native.spdx.json
    (matched in manifest-x86_64-zlib-native.create_spdx)
Please adjust the recipes so only one recipe provides a given file.


However, if I destroy the build directory and run again the command, it 
successfully generates meta-world-recipe-sbom-recipe-sbom.spdx.json

And in this case, the software_Package providing the static library is 
created, 
and the application "dependsOn" this static library.
It also "dependsOn" gcc-cross-arm (a software_Package), which is great.
*But* there is no way to know that gcc-cross-arm package is a native package.

> This SBoM uses new "recipe" packages that _should_ be sufficient to do
> CVE analysis, but let me know if anything is missing; it also is
> pretty quick to generate since it doesn't require doing a build.


> We actually already track this for the SPDXDocument class as an
> extension, since the native recipes need to handle a few things
> differently. We could pretty easily add a similar extension to the new
> recipe package that you could look at.

Unless I'm mistaken, this information is not provided in the SBOM that can be 
found in the deploy directory.

The following command does not return anything:

python3 -m json.tool build/tmp/deploy/images/qemuarm/core-image-minimal-
qemuarm.rootfs.spdx.json | grep -E "is.native"

Same result with meta-world-recipe-sbom-recipe-sbom.spdx.json

> 
> >  - If possible (though not a priority), including layer information
> >  
> >    (URL, Git version, etc.) associated with a `build_Build` object would
> >    be
> >    valuable.
> 
> We would like to do that and it's on the backlog. It's a little bit
> tricky to get right, especially when dealing with multiple remotes in
> the git repos, bbapends, etc. FWIW, our Yocto PURLs support this also,
> we just don't have it implemented.

Yeah, I know finding all the layers that impact a recipe could be tricky...

> It also probably shouldn't be attached to the `build_Build`, but the
> new "recipe" package (See below). I'm hoping you can now completely
> ignore the build provenance information for CVE analysis now (unless
> you want it to filter on source files or something). In fact, with the
> new recipe packages, we could make the build provenance optional in
> the SBoM output.

I currently use the `build_Build` in sbom-cve-check. The goal is to speed up 
CVE analysis, since a recipe should only provide "one" CPE (there can be 
multiple CPEs, but they all identify the same "component") and one version.

From the `build_Build` object, the packages are grouped (if they share the 
same 
CPEs and version), and the analysis is done on this group. This is especially 
important for the kernel and associated modules. We could have hundreds of 
kernel packages sharing the same CPE.

I noticed that the `build_Build` object is no longer used when generating
meta-world-recipe-sbom-recipe-sbom.spdx.json. sbom-cve-check currently cannot 
handle that, but I could change the way it works, will see. We really need to 
discuss that.

> > "Better" might be too strong, we support *more* data sources.
> > Sometimes, version ranges in the CVE List are incorrect, while the NVD
> > database may provide more accurate information. However, users can
> > configure their preferred data sources via a custom configuration file,
> > so this isn’t a major concern from my perspective.
> 
> I think there is also a lot of value in a separate tool that can be
> updated independently to deal with new sources using the same SPDX
> data. For example, if we ever figure out a sane thing to do with PURLs
> for vulnerability management, using e.g. OSV might be an option also
> (esp. since the PURLs are already in the SPDX data).

Indeed OSV might be added as an additional database. But I need to find the 
"time" to do that. There is so much to do :)

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: Comparing cve-check with sbom-cve-check

[Joshua Watt]

On Fri, Feb 6, 2026 at 5:22 AM Benjamin ROBIN
<benjamin.robin@bootlin.com> wrote:
>
> Hello Joshua,
>
> On Thursday, February 5, 2026 at 6:29 PM, Joshua Watt wrote:
> > I think I have the SPDX changes that will be required _mostly_ ready
> > for you to look at:
> > git.openembedded.org/openembedded-core-contrib/log/?h=jpew/recipe-sbom
>
> Thank you. I am currently evaluating your commits.
>
> While being able to generate a SBOM for an entire layer is useful, the
> urgency, in my opinion, is to have a SBOM (the one that can be found in the
> deploy folder) with all the important information for a complete analysis:
> - Elements (packages) "installed" on the target.
> - And also build elements (what you have created: software_Package with
>   software_SoftwarePurpose.specification).
>
> Users are doing the build anyway; the generated SBOM associated with the build
> should contain "everything" for a proper CVE analysis. But I guess the commits
> that you have written are a first test, and it is not complete.
>
> > Run the command:
> > ```
> > bitbake -c create_recipe_sbom meta-world-recipe-sbom
> > ```
> > Which will make a complete recipe-level SBoM (names may change, since
> > "recipe" is a little confusing in this context) in
> > ${DEPLOY_DIR_IMAGE}/meta-world-recipe-sbom-recipe-sbom.spdx.json
>
> This is great; it will be very useful for a layer maintainer.
>
> But on my side, I first tried a normal build with an empty build directory.
> The build failed around SPDX generation. For information I used the following
> KAS configuration:
>
> -------------------
> header:
>   version: 18
>
> build_system: openembedded
> machine: qemuarm
> distro: poky
> target: core-image-minimal
>
> repos:
>   bitbake:
>     url: https://git.openembedded.org/bitbake
>     commit: af9dd012e7f4d16dccd1d6118be5da94ede68f85
>     branch: master
>     path: layers/bitbake
>     layers:
>       .: disabled
>
>   openembedded-core:
>     url: https://git.openembedded.org/openembedded-core-contrib
>     #commit: 6ce19709f7835ee5cd7915e181f89397975236c8
>     commit: 43737d14ab039c507a1a71177da68c7b41e4622f
>     branch: jpew/recipe-sbom
>     path: layers/openembedded-core
>     layers:
>       meta:
>
>   meta-yocto:
>     url: https://git.yoctoproject.org/meta-yocto
>     commit: de4abc0a175af12eacc761a2e1e60ca7fdfeaa1b
>     branch: master
>     path: layers/meta-yocto
>     layers:
>       meta-poky:
>
>   meta-openembedded:
>     url: https://git.openembedded.org/meta-openembedded
>     commit: 3787ecadbb198f56ac43025a15b3339c810c3a66
>     branch: master-next
>     path: layers/meta-openembedded
>     layers:
>       meta-oe:
>       meta-python:
>       meta-networking:
>
>   meta-sbom-cve-check:
>     url: https://github.com/bootlin/meta-sbom-cve-check.git
>     commit: ea9fecee6073abab0f8d5d7ccb02077d1c6dc504
>     branch: main
>     path: layers/meta-sbom-cve-check
>
> local_conf_header:
>   cleanup: |
>     INHERIT += "rm_work"
>   spdx: |
>     INHERIT += "vex"
> -------------------
>
> If I am using commit 6ce19709f7835ee5cd7915e181f89397975236c8 everything
> works, but static libraries are not listed (no associated package). But this
> is
> expected, since none of your changes were included.
>
> If I try to switch to your commit (43737d14ab039c507a1a71177da68c7b41e4622f)
> and run: bitbake -c create_recipe_sbom meta-world-recipe-sbom
> I have the following errors (a lot of them) if I do not destroy the build
> directory:
>
> ERROR: zlib-native-1.3.1-r0 do_create_recipe_spdx_setscene: Recipe zlib-native
> is trying to install files into a shared area when those files already exist.
> The files and the manifests listing them are:
>   /work/build/tmp/deploy/spdx/3.0.1/x86_64/by-spdxid-hash/
> 70/706d8ec1deffb40c8b72ba34c22aaf543671078abd1a000c5fa0ee6f35274d2b.spdx.json
>     (matched in manifest-x86_64-zlib-native.create_spdx)
>   /work/build/tmp/deploy/spdx/3.0.1/x86_64/recipes/recipe-zlib-
> native.spdx.json
>     (matched in manifest-x86_64-zlib-native.create_spdx)
> Please adjust the recipes so only one recipe provides a given file.
>
>
> However, if I destroy the build directory and run again the command, it
> successfully generates meta-world-recipe-sbom-recipe-sbom.spdx.json

Ya, this is because I tried to "reuse" the recipe deploy directory for
do_create_recipe_spdx; I can fix this.


>
> And in this case, the software_Package providing the static library is
> created,
> and the application "dependsOn" this static library.
> It also "dependsOn" gcc-cross-arm (a software_Package), which is great.
> *But* there is no way to know that gcc-cross-arm package is a native package.
>
> > This SBoM uses new "recipe" packages that _should_ be sufficient to do
> > CVE analysis, but let me know if anything is missing; it also is
> > pretty quick to generate since it doesn't require doing a build.
>
>
> > We actually already track this for the SPDXDocument class as an
> > extension, since the native recipes need to handle a few things
> > differently. We could pretty easily add a similar extension to the new
> > recipe package that you could look at.
>
> Unless I'm mistaken, this information is not provided in the SBOM that can be
> found in the deploy directory.
>
> The following command does not return anything:
>
> python3 -m json.tool build/tmp/deploy/images/qemuarm/core-image-minimal-
> qemuarm.rootfs.spdx.json | grep -E "is.native"
>
> Same result with meta-world-recipe-sbom-recipe-sbom.spdx.json

Yes, sorry. My statement was not clear; you won't find any native
markers in the SBoM output today, but we have mechanisms in place to
do that, so it should be pretty easy and I can work on it.

>
> >
> > >  - If possible (though not a priority), including layer information
> > >
> > >    (URL, Git version, etc.) associated with a `build_Build` object would
> > >    be
> > >    valuable.
> >
> > We would like to do that and it's on the backlog. It's a little bit
> > tricky to get right, especially when dealing with multiple remotes in
> > the git repos, bbapends, etc. FWIW, our Yocto PURLs support this also,
> > we just don't have it implemented.
>
> Yeah, I know finding all the layers that impact a recipe could be tricky...
>
> > It also probably shouldn't be attached to the `build_Build`, but the
> > new "recipe" package (See below). I'm hoping you can now completely
> > ignore the build provenance information for CVE analysis now (unless
> > you want it to filter on source files or something). In fact, with the
> > new recipe packages, we could make the build provenance optional in
> > the SBoM output.
>
> I currently use the `build_Build` in sbom-cve-check. The goal is to speed up
> CVE analysis, since a recipe should only provide "one" CPE (there can be
> multiple CPEs, but they all identify the same "component") and one version.
>
> From the `build_Build` object, the packages are grouped (if they share the
> same
> CPEs and version), and the analysis is done on this group. This is especially
> important for the kernel and associated modules. We could have hundreds of
> kernel packages sharing the same CPE.
>
> I noticed that the `build_Build` object is no longer used when generating
> meta-world-recipe-sbom-recipe-sbom.spdx.json. sbom-cve-check currently cannot
> handle that, but I could change the way it works, will see. We really need to
> discuss that.

Right, it kinda depends on your use case. There are basically two of
them right now:
1) Running CVE analysis on all recipes to determine if any _recipes_
have new CVEs that need to be triaged. This should be doable without
actually having to build the recipes, since that would take a long
time. This is the more "proactive" CVE maintenance that upstream and
many companies want to do.
2) Running CVE analysis on a specific product SBoM to determine if
there are any CVEs that affect that product. Your tool currently
handles this really well.

I've not looked too closely at the code for your tool, but I'm hoping
that it wouldn't be too difficult to handle either use case. I'm kinda
thinking the tool should be able to handle either, since the SBoM for
#2 is just a superset of #1. If there is something that we need to do
to the SBoM to clearly distinguish the difference between them so your
tool can do the right thing, let me know.

>
> > > "Better" might be too strong, we support *more* data sources.
> > > Sometimes, version ranges in the CVE List are incorrect, while the NVD
> > > database may provide more accurate information. However, users can
> > > configure their preferred data sources via a custom configuration file,
> > > so this isn’t a major concern from my perspective.
> >
> > I think there is also a lot of value in a separate tool that can be
> > updated independently to deal with new sources using the same SPDX
> > data. For example, if we ever figure out a sane thing to do with PURLs
> > for vulnerability management, using e.g. OSV might be an option also
> > (esp. since the PURLs are already in the SPDX data).
>
> Indeed OSV might be added as an additional database. But I need to find the
> "time" to do that. There is so much to do :)

Waiting on this seems best. It's not clear what the best long-term
solution is going to be right now, and I wouldn't want to spend time
developing a solution that was a dead end.


>
> --
> Benjamin Robin, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
>
>

Re: Comparing cve-check with sbom-cve-check

[Benjamin ROBIN]

On Friday, February 6, 2026 at 4:50 PM, Joshua Watt wrote:
> > But on my side, I first tried a normal build with an empty build
> > directory.
> > The build failed around SPDX generation. For information I used the
> > following KAS configuration:

I should have specified that when building a minimal image with your branch, I 
have the following error:

ERROR: opkg-utils-native-0.7.0-r0 do_create_recipe_sbom: Could not find a 
recipes SPDX document named recipe-opkg-utils-native
ERROR: Logfile of failure stored in: /work/build/tmp/work/x86_64-linux/opkg-
utils-native/0.7.0/temp/log.do_create_recipe_sbom.113690
ERROR: Task (virtual:native:/work/build/../layers/openembedded-core/meta/
recipes-devtools/opkg-utils/opkg-utils_0.7.0.bb:do_create_recipe_sbom) failed 
with exit code '1'

I am not able to build an image using your branch.

> > -------------------
> > 
> > header:
> >   version: 18
> > 
> > build_system: openembedded
> > machine: qemuarm
> > distro: poky
> > target: core-image-minimal
> > 
> > repos:
> >   bitbake:
> >     url: https://git.openembedded.org/bitbake
> >     commit: af9dd012e7f4d16dccd1d6118be5da94ede68f85
> >     branch: master
> >     path: layers/bitbake
> >     
> >     layers:
> >       .: disabled
> >   
> >   openembedded-core:
> >     url: https://git.openembedded.org/openembedded-core-contrib
> >     #commit: 6ce19709f7835ee5cd7915e181f89397975236c8
> >     commit: 43737d14ab039c507a1a71177da68c7b41e4622f
> >     branch: jpew/recipe-sbom
> >     path: layers/openembedded-core
> >     
> >     layers:
> >       meta:
> >   meta-yocto:
> >     url: https://git.yoctoproject.org/meta-yocto
> >     commit: de4abc0a175af12eacc761a2e1e60ca7fdfeaa1b
> >     branch: master
> >     path: layers/meta-yocto
> >     
> >     layers:
> >       meta-poky:
> >   meta-openembedded:
> >     url: https://git.openembedded.org/meta-openembedded
> >     commit: 3787ecadbb198f56ac43025a15b3339c810c3a66
> >     branch: master-next
> >     path: layers/meta-openembedded
> >     
> >     layers:
> >       meta-oe:
> >       meta-python:
> >   
> >       meta-networking:
> >   meta-sbom-cve-check:
> >     url: https://github.com/bootlin/meta-sbom-cve-check.git
> >     commit: ea9fecee6073abab0f8d5d7ccb02077d1c6dc504
> >     branch: main
> >     path: layers/meta-sbom-cve-check
> > 
> > local_conf_header:
> >   cleanup: |
> >   
> >     INHERIT += "rm_work"
> >   
> >   spdx: |
> >   
> >     INHERIT += "vex"
> > 
> > -------------------



> Ya, this is because I tried to "reuse" the recipe deploy directory for
> do_create_recipe_spdx; I can fix this.

Thanks.

> > Unless I'm mistaken, this information is not provided in the SBOM that can
> > be found in the deploy directory.
> > 
> > The following command does not return anything:
> > 
> > python3 -m json.tool build/tmp/deploy/images/qemuarm/core-image-minimal-
> > qemuarm.rootfs.spdx.json | grep -E "is.native"
> > 
> > Same result with meta-world-recipe-sbom-recipe-sbom.spdx.json
> 
> Yes, sorry. My statement was not clear; you won't find any native
> markers in the SBoM output today, but we have mechanisms in place to
> do that, so it should be pretty easy and I can work on it.

Oh, OK. I was confused because, when I was looking at the code, this was 
indeed not implemented.

> > I currently use the `build_Build` in sbom-cve-check. The goal is to speed
> > up CVE analysis, since a recipe should only provide "one" CPE (there can
> > be multiple CPEs, but they all identify the same "component") and one
> > version.
> > 
> > From the `build_Build` object, the packages are grouped (if they share the
> > same
> > CPEs and version), and the analysis is done on this group. This is
> > especially important for the kernel and associated modules. We could have
> > hundreds of kernel packages sharing the same CPE.
> > 
> > I noticed that the `build_Build` object is no longer used when generating
> > meta-world-recipe-sbom-recipe-sbom.spdx.json. sbom-cve-check currently
> > cannot handle that, but I could change the way it works, will see. We
> > really need to discuss that.
> 
> Right, it kinda depends on your use case. There are basically two of
> them right now:
> 1) Running CVE analysis on all recipes to determine if any _recipes_
> have new CVEs that need to be triaged. This should be doable without
> actually having to build the recipes, since that would take a long
> time. This is the more "proactive" CVE maintenance that upstream and
> many companies want to do.
> 2) Running CVE analysis on a specific product SBoM to determine if
> there are any CVEs that affect that product. Your tool currently
> handles this really well.
> 
> I've not looked too closely at the code for your tool, but I'm hoping
> that it wouldn't be too difficult to handle either use case. I'm kinda
> thinking the tool should be able to handle either, since the SBoM for
> #2 is just a superset of #1. If there is something that we need to do
> to the SBoM to clearly distinguish the difference between them so your
> tool can do the right thing, let me know.

Yes, if I understood correctly, #2 will be a superset of #1. But sbom-cve-
check relies (for now) on build_Build which is included in #2 (but not in #1). 
So this is not going to work for #1.

sbom-cve-check heavily relies on the concept of a build (recipe), which 
provides: sources and packages.

Since I am not able to generate a "normal" SBOM file associated with a built 
image, I can check what would be the format of this SBOM after the changes 
that you have made.

> Waiting on this seems best. It's not clear what the best long-term
> solution is going to be right now, and I wouldn't want to spend time
> developing a solution that was a dead end.

Yes, I agree.

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Mark Hatle]

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

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

--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]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

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

[Joshua Watt]

On Fri, Feb 6, 2026 at 10:22 AM Mark Hatle
<mark.hatle@kernel.crashing.org> 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 (#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]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >

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

[Mark Hatle]

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.

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

--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]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

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

[Joshua Watt]

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

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 (#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]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >

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

[Mark Hatle]

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]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>