On Wed, Jun 3, 2026 at 8:05 PM Paul Barker <[email protected]> wrote:
> 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. >From my point of view, layers are ingredients like downloaded packages. Without including layers, what is the provenance of: - base-files ? - all patches applied during the build from recipes - configuration files generated by recipes ? Kind regards, Marta
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2387): https://lists.openembedded.org/g/openembedded-architecture/message/2387 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]] -=-=-=-=-=-=-=-=-=-=-=-
