> So what if you use a library to do one thing that just happens to do 100 other things (this having a much larger attack surface and bug potential)? I’ve wond

> So what if you use a library to do one thing that just happens to do 100 other things (this having a much larger attack surface and bug potential)? I’ve wondered about this for a while, and one idea that’s crossed my mind is whether compiler stages could be introduced to do this. For example, you add a dependency, you use a few methods and structures. You compile it, the compiler goes through your code, looks at what traits, implementations, etc that you do and don’t use, it grabs just the code required to satisfy these, and proceeds as normal. At the end it spits out a little report for you telling you what specific things it included/excluded from your binary/library. Like tree-shaking in JS but better. Maybe this already happens during dead-code-elimination passes, or during some other compiler step, maybe most of our libraries are far too interconnected/non-modular to be able to do this without ending up with the whole dependency anyway, maybe it’s computationally infeasible due to some result in Computer Science, I don’t know-and wouldn’t really know where to look to find out-but if it could be done, and if we could go even further to embed this metadata into the resulting binary itself, we’d at least have a provable way of saying “my application is safe from x because it does not include <vulnerable part of lib y>”. I imagine to do this, you’d need to operate on source code-unless there’s some magic way to do it with precompiled binaries-and runtime dynamism would make things extra difficult, but it’s an interesting idea.