On Thu, 2026-06-04 at 13:12 +0200, Marta Rybczynska via lists.openembedded.org wrote: > 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 ?
Hi Marta, I just built core-image-minimal and checked the resulting .spdx.json file. For base-files, we have all files copied in from the layer listed as software_File type entries with sha256 & sha512 hashes. These are connected to the package via a LifecycleScopedRelationship type entry with relationshipType = hasInput. So I think those are covered. > - all patches applied during the build from recipes All patch file are similarly listed as source files. E.g. for acl we have four sources listed in the hasInput relationship, corresponding to the source tarball and three patch files, all of which have hashes. > - configuration files generated by recipes Do you have an example of this? I can check the output and see how it is represented. 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 (#2388): https://lists.openembedded.org/g/openembedded-architecture/message/2388 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]] -=-=-=-=-=-=-=-=-=-=-=-
