It sounds like static linking would also hide CVEs that do affect the functions that were compiled into and are used by your statically linked binary in a way that would introduce security issues for that binary.
BTW IIRC normal static linking doesn't strip out all unused functions, you need LTO (Link Time Optimisation) to do that.
Normal static linking does not include objects that aren’t referenced. If you put every function in its own object file, then unused functions will not be linked in, regardless of how many objects files are in the library. If you have 10,000 functions in two object files, then you can link none, either, or both - all sunsets of object files, but likely many unused functions.
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.
The wide gap between those two options is kind of dissatisfying, it would be cool if LTO could disassemble existing object files and do the unused code removal on the assembly language layer. I guess that Facebook BOLT and Google Propeller are working on an approach like that.
BTW IIRC normal static linking doesn't strip out all unused functions, you need LTO (Link Time Optimisation) to do that.