On Fri, Feb 6, 2026 at 5:22 AM Benjamin ROBIN <[email protected]> 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 > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#230627): https://lists.openembedded.org/g/openembedded-core/message/230627 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]] -=-=-=-=-=-=-=-=-=-=-=-
