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.

advantages of static linking reducing size and attack surface When performing (static) linking, we pass the “–as-needed” and “–gc-sections” flags to the linker. Essentially, this results in only symbols being included in the resulting (static) binary that are really needed - not the entire library archive. This (in combination with using “-fdata-sections -ffunction-sections” at compile time of the static libraries) results in only the used functions of the library to be present in the resulting (static) binary.

static linking not so harmful in container context - when done right There a few articles out there that doom static linking. While there is a valid point behind every argument and most - if not all - of them are 100% applicable to a standard Linux system, it may not be exactly applicable to a containerized environment. So I’m picking one article (without intended pun to the author) and try to put this into container context - again, without saying that the author isn’t completely right in general.