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
<[email protected]> 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 <[email protected]> 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
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#230587):
https://lists.openembedded.org/g/openembedded-core/message/230587
Mute This Topic: https://lists.openembedded.org/mt/117638558/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
