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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#230618):
https://lists.openembedded.org/g/openembedded-core/message/230618
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]]
-=-=-=-=-=-=-=-=-=-=-=-
