Add option to limit SBOM content to packages added to the rootfs

[Jasper-Ben]

Currently, meta-cyclonedx will add any package that is built for the target architecture to the SBOM.

This might be desirable, as the package list might be incomplete otherwise (e.g. code might "spill over" from one package to another when doing static linking), however on the flip-side this also drastically increases the number of packages included in the sbom, with most of them not being relevant at runtime (see: #3 (comment)).

So while both options are not ideal, it would be great to be able to leave it up to the user to decide whether drastically limiting the number of packages in the SBOM is worth the (probably manageable) risk of potentially losing track of a handful of packages that do somehow end up on the target "undetected".

For this to work, we need to restructure the way meta-cyclonedx creates the SBOM file, as the information which packages end up in the rootfs is only available after the image rootfs has been constructed and not in the context of a component recipe (see: #7 (comment))

[groetingc]

Hi @Jasper-Ben !
Could the way of creating a SBOM done similar as Yocto's default https://git.yoctoproject.org/poky/tree/meta/classes/create-spdx.bbclass?h=kirkstone class does a good starting point? It looks more complex but it also uses the image_list_installed_packages to ensure that only packages are listed in the SBOM, which are really installed.
A usage of that class in conjunction of a transformation tool convertings a SPDX bom to CycloneDX bom could be also an option, isn't it?
BR,
Claus

[Jasper-Ben]

A usage of that class in conjunction of a transformation tool convertings a SPDX bom to CycloneDX bom could be also an option, isn't it?

@groetingc You could look into that if you want, but I am not sure how well these tools work. The output of the create-spdx class is quite complex with multiple SBOMs referencing each other. It also contains a lot of information that we (at least for our use-case of CVE monitoring) aren't currently interested in. I have tried working with the SPDX java and python tools in the past and had a horrible experience with large SPDX files such as the Yocto ones. Though, I am not sure how the current state of things are now.

Personally, I feel like for the time being it would be easier and quicker to just change our current setup to write the bom information into temporary files and then have a post build task collect these into the final output while using the image_list_installed_packages function.

[Jasper-Ben]

@groetingc FYI, I will start working on this next. However, I am on vacation for two weeks starting from next week. I don't think I'll be able to finish this before then, so there will be a slight delay

[iat-coder]

That would be a great feature to have. Instead of a switch - maybe just output both SBOMs (build-time and run-time)?
I needed this recently and ended up hacking poky classes (sieve through the generated SBOM and only keep those that relate to the installed packages). Achieved what I needed but very messy. I think image_list_installed_packages is only available in the image layer, not sure how to get a list of installed packages otherwise.

A run-time SBOM is essential when it comes to cybersecurity risk analysis as it significantly reduced the number of components and therefore the number of CVEs associated with them.

[Jasper-Ben]

👋 @iat-coder what would be your use-case for having both? Just to clarify, the "build-time" sbom would currently be build-time PLUS run-time, NOT only build-time.

[iat-coder]

There is probably some value in having build-time dependencies SBOMed. But I'd say it's more out of academic interest. One can argue that a vulnerability in your build chain can lead to another vulnerability in your product. But for practical scenarios we only need to SBOM components in the final image. So my suggestion would be to exclude build-time and only have run-time items in there.