On Wed, 2026-06-03 at 13:22 +0200, Marta Rybczynska via lists.openembedded.org wrote: > Hi all, > > While reviewing the SPDX 3.0 SBOMs currently generated by OE-Core master, I > noticed that they do not appear to contain information about the layers > used for the build, their versions/revisions, or the bbappends that > influenced the final metadata. > > This raises an interesting question from a vulnerability management > perspective. > > Today, the generated SBOM contains information about the produced software > packages, their dependencies, files, licenses, ... However, it does not > provide visibility into the layers and metadata that actually controlled > how those packages were built. > > As a result, vulnerabilities in build metadata itself are effectively > invisible to SBOM-based vulnerability management tools. > > Examples include: > > - Vulnerabilities in bitbake and related tools. > - Vulnerabilities in fetchers. > - Command injection or arbitrary code execution issues in metadata > processing. > - Insecure or vulnerable default configurations introduced through > recipes or bbappends. > - Security-relevant behavior implemented in layer-provided tooling. > > For example, consider the recent npm fetcher issue in BitBake. The fetcher > was enabled by default in various versions and was clearly > security-relevant. As far as I know, no CVE exists for this issue today, > but if one were assigned, current SBOM consumers would have no way to > determine whether a product was built with a vulnerable version of the > affected component. > > One possible argument is that such issues belong to a "build SBOM" rather > than the product SBOM. I think this is somewhat borderline in the case of > OpenEmbedded. Layers, recipes, classes, and bbappends influence the > resulting software far more directly than many other tools present on the > build host. In practice, they are part of the build logic used to create > the final product. > > Because of this, I believe the minimum information that should be included > in the generated SBOM is: > > - The list of layers used for the build. > - The version or revision of each layer. > - Potentially the exact source revision used for each layer repository. > > It may also be worth considering whether layers should have a more explicit > and consistently available versioning mechanism... (but that in step 2) > > When we have the list of layers, we also have information on bbappends, so > that does not need to be directly present. > Some of this (or most) is available with SPDX_INCLUDE_BUILD_VARIABLES = "1" > and > SPDX_INCLUDE_BITBAKE_PARENT_BUILD = "1", but in a non-standard and > non-portable way. > > What do you think?
The SBOM is a Bill of Materials, aka a list of ingredients. We should not try to capture all information about the build environment in this. I think the place for this is in SLSA/in-toto attestations. That would allow the SBOM to be handled in a way compatible with our sstate caching, while capturing the bitbake and layer checksums as inputs to the build process. Best regards, -- Paul Barker
signature.asc
Description: This is a digitally signed message part
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2381): https://lists.openembedded.org/g/openembedded-architecture/message/2381 Mute This Topic: https://lists.openembedded.org/mt/119626760/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
