[fathermarz]

As someone in the Software Supply Chain business. Yocto SBOMs are considered low quality because they include things that do and do not exist in the final compiled artifact. When you compare what exists inside, physically from a binary perspective, what is included in the manifest, and what is generated in the build root, you will find they will never align unless you get creative and map artifacts together. Today they are accepted as meeting the compliance checkbox, but once the industry matures, they will need to adjust their approach.

[Coi-l]

May I ask what you recommend?

Since it is easy for me I prefer the Yocto SBOM, but the security side forces blackduck binary scanning on us which while finding most things on the binary constantly misidentifies a lot of versions, resulting in a lot of manual work.

It also does not know which patches Yocto has applied for fixing CVEs.

And none of these can figure out what is in the kernel and therefor triggers an ungodly amount of CVEs in parts of the kernel we don't have compiled in.

[fathermarz]

There is no tool at the moment that solves this, but it is being worked on amongst some players in the industry by those that fundamentally understand the problem. It is a very niche skill set that the greater compliance world doesn’t understand the need for yet. I would say we are 1-3 years away from solving the noise problem of SCA/BCA.

[svnt]

How would yocto adjust their approach to improve their SBOM output?

It would seem to be a nearly impossible thing to automate.

[fathermarz]

To be clear, it isn’t just a yocto problem. It is an industry wide issue and usually requires resolution between binary, build, and manifest or SCA. But at the end of the day developers are still very creative.