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

[Benjamin ROBIN <benjamin.robin@bootlin.com>]

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