On Wed, Jun 3, 2026 at 10:53 AM Leonardo Costa <[email protected]> wrote: > > > We are planning to release SPDX SBOMs along with our images to provide > > package > > information about the software components that make them up. > > > > As it currently stands today, bootloader components are not included in the > > final SBOM generated for the image. In particular, for our machines based on > > i.MX SoCs, the imx-boot container, along with boot components (ATF, SECO, > > SCFW) > > have their SPDX files generated in spdx/, but not included in the image > > SBOM. > > > > If I understand correctly, the SBOM is generated by looking at the packages > > in > > the rootfs, and recursively adding their SPDX entries along with the ones > > for > > their dependencies. In our builds, I found that U-Boot does get included in > > the SBOM, but in our particular case this seems to be due to the presence of > > libubootenv in the rootfs, which has the U-Boot recipe in its dependency > > chain, > > so the inclusion of U-Boot in the SBOM is only a side effect. > > > > I have not seen anyone raise this as an issue, but my intuition is that this > > information should be included in the SBOM. Despite not making it to the > > rootfs, these boot components are still part of the image. CVE information > > about them, for example, is relevant to users. > > > > My question is, is there any configuration that should be set to include > > these > > components? I couldn't find anything about this in the documentation or in > > the > > code. If there is no configuration regarding this, would a contribution to > > add > > components such as these be welcome? > > Following up on this, I just wanted to know if this behavior is intended to > stay as it currently is or if it's worth working on a patch to add components > beyond the ones that are in the final rootfs.
It is a known limitation that things that are not in the root filesystem image are not included in the SBoM. The biggest problem is that it is quite tricky to figure out how to correctly indicate that a given non-image task is building an "aggregate" of some other things and thus needs to produce an aggregated SBoM, along with the dificultlies of plumbing in SBoM generation to arbitrary tasks. Image tasks are much simpler to solve because they are well formed in how they operate. If you have suggestions for how to deal with this, I would welcome them. > > Kind regards, > > Leonardo
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#238103): https://lists.openembedded.org/g/openembedded-core/message/238103 Mute This Topic: https://lists.openembedded.org/mt/119502448/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
