Honest question: what's the difference between storing dependencies in the executable (statically) and storing them in the Docker image?
OTOH, container images seem to be bloated by unused binaries and completely unused libraries, not unused functions in shared libraries.
Here are some possible advantages I can think of: less surface area for security, less surface area for maintenance, smaller container image, implying faster time to pull image, and perhaps also faster time to boot image.
Disadvantages: you have to do the work to set it up in the first place and maintain it (putting in extra effort to avoid adding superfluous dependencies in future), while the above advantages may be marginal.
This might also be true if you simply copy shared libraries. AFAICT these scanners rely on the package index to identify potential CVE exploits. But I may be wrong, and in any event it'd be much more difficult to identify the version of a statically linked library than a shared library, which can be identified by its name or hash.
This doesn't excuse avoiding keeping containers updated, but if you want to be cynical about vulnerability management, i.e. that any trick which improves the signal-to-noise ratio is worth exploring, then it's something to keep in mind.
BTW IIRC normal static linking doesn't strip out all unused functions, you need LTO (Link Time Optimisation) to do that.
LTO does something more complex than just pick the right routines - it does the last few compilation/optimization stages when you run the linker. As a result, you get to inline across modules, drop some unused functions and more - however, this would only work for object files that were properly LTO compiled themselves. If you have e.g. a third party library that wasn’t LTO compiled for your specific tool chain, you are back to the “whole object file or bust” link regime.
https://github.com/facebookincubator/BOLT https://www.phoronix.com/scan.php?page=news_item&px=Google-P...
The only edge case I can think of is if you could use it for ROPing some gadgets from the unused functions, but that's pretty unlikely and the gadgets are usually not that unique.
Most advantages are in performance: smaller size, faster loading, better cache usage.
Shared libraries, at least, allow more automated updates, but containers are still a problem.
I did this just recently by hand when I wanted to run a source-only binary in my dom0 but didn't want to build it in the dom0. I built it in a container, checked what shared libraries it wanted with `ldd path/to/binary` inside the container, copied all of the referenced libraries to ~/libs, then copied that dir and the binary to dom0 and ran it with `LD_LIBARARY_PATH=$HOME/libs path/to/binary`, worked perfectly.
The 5 W's[1] aren't just for journalists.
You can make a smaller tar file by including just the static file (less inodes/wasted file space of deps linking to each other/unnecessary extra function call data). And technically static files can sometimes execute faster (depending on page/cpu cache etc). But the advantages of static are much smaller when you consider the advantages to dynamic in a tar file - and even more advantages in a container.
So while there can be advantageous, they are vanishingly small.
It’s a lock on the door - keeps honest people honest and erroneous rm -rf confined. But it might not stop a determined hacker.