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

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

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