On Thu, Jun 4, 2026 at 2:27 PM Paul Barker <[email protected]> wrote:
> 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. > And what is their provenance then? They have no download link, I guess. I think it is a problem. Isn't it? > > > - configuration files generated by recipes > > Do you have an example of this? I can check the output and see how it is > represented. > Device tree generated by uboot-sign.bbclass as an example I have been recently looking into. Kind regards, Marta
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2389): https://lists.openembedded.org/g/openembedded-architecture/message/2389 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]] -=-=-=-=-=-=-=-=-=-=-=-
