About

advantages of spartan containers

Advantages of spartan containers over similar projects (Chainguard and Google Distroless)

Function usage documentation

Losing dependency information would be a killer argument against static linking. We put some effort into documenting what we (statically) link. Having that documentation has a huge advantage: you don’t only know which library you are using, you also know which functions of the library are actually used. So the next time a vulnerability of one of your used libraries becomes public, fear not: You may be able to tell (and prove) that this vulnerability doesn’t even exist in your environment. So while some scanners may report it’s there (based on the fake-presence of the library), during analysis you have all information you need to tell if it’s applicable or not. Unfortunately, the structured section of both, CPEs and CVEs do not go into enough detail to automate this process. But maybe it’s possible in the future.

embedded notes

As mentioned above, we add package metadata (specifically .note.package and an annobin note) to our binaries. Note.package has been introduced by the folks at FreeDesktop (https://systemd.io/ELF_PACKAGE_METADATA/). This approach has been adopted by Fedora (since Fedora 36) and I’d expect other distributions to follow. Binary-analysis tools (e.g. see syft) may make use of this information to get some details - indepedent of package managers. Annobin is a combination of compiler plugin and verification engine by RedHat. It will make the entire chain visible that led to a binary and will also expose compile time information for checking against your standards. For the time being, we also keep package management information around (in the debug artifact) though.

hardened profile

As mentioned above, all packages inside our container images are using the “hardened” Gentoo profile. This enables FORTIFY_SOURCE=3, SSP, SCP, RELRO (incl. BIND_NOW) and CET. For the future we also look into SELinux support and static-pie support.