Software supply chain trust

My desire to evaluate distributions, containers and flatpaks continue. The trustworthiness of software is in question with lots of efforts in the works. One recent presentation had a slide that showed an analysis of a container.

Does fedora have any automated analysis of software or SBOM in the build infrastructure? It would be nice to fail a package if it uses something known to be problematic.

How can I analyze a flatpak from flathub? If the SBOM is provided and analyzes as okay, how can I be sure nothing was modified from upstream when included in the flatpak? Can flatpaks be whitlisted/blacklisted on fedora? By default blacklisting everything and only whitelisting “clean” applications/runtimes I would be more inclined in allowing them. It does not seem like anything that flathub will do so doing it as a service provided by fedora would make sense.

We do not currently, although note that all official Fedora containers and flatpaks are built from Fedora RPMs, and every build can be traced back from binary RPM through the koji build system back to dist-git. In cases where packages bundle (or “vendor”) other packages, our guidelines call for that to be encoded in the package specfile. A SBOM[1] could be generated from information (within the limitations of automatic generation, of course).

I see that the presentation you’ve linked was by @defolos — perhaps he can expand more!

Since this is The Water Cooler, it’s fine to talk about this here… but https://discourse.flathub.org/ might get you closer to an answer for Flathub in specific.


  1. “software bill of materials” ↩︎

2 Likes

What I showed in the talk was only a trivy scan of a container image, but that cannot be directly translated to flatpaks nor does it tell you anything about a secure supply chain.

It is however in possible to create an SBOM from a container & flatpak build, as long as the build is performed in some kind of isolated environment like in OBS, koji, or OSBS. OBS for instance can be configured to create SBOM files for container based builds.

I don’t have high hopes for any kind of SBOM support in flatpak. Flatpak builder allows you to perform anything that you want, as does a Dockerfile. Hence, you can put anything into your container and your flatpak. You can only obtain strong supply chain guarantees if you build in a sealed environment from trusted sources (e.g. only from the koji buildroot).


  1. “software bill of materials” ↩︎

2 Likes

Great insight!

I will continue to evaluate what I am willing to trust with no change from even this comment on another discussion.

This is a hard problem. I really appreciate the work done to maintain build environments where open source projects can engender confidence that the resultant binaries are unlikely to have been compromised. Efforts like grub2 source code analysis to reduce risks are helpful too.