From your perspective, the application itself is untrusted un-vetted third-party code until you yourself have vetted it, no? The fact that you also have to vet dependencies is meaningless implementation detail. You’ve got a bucket of code, you want to run it on your machine, and you decide that you want to vet it first. How does a package boundary change that? You’re describing security theatre.
> The fact that you also have to vet dependencies is meaningless implementation detail.
I disagree. minimizing dependencies means reducing the risk exposure. That's not meaningless.
What I'm really talking about is a cultural change where package managers have made it so easy to just throw a package at a problem that devs tend to do this too much. People using packages to do simple things, people using packages without understanding what the packages do, etc.
Every time an application uses a library or package of any sort, that decreases the security of the application. So it's a tradeoff, and I think that too many devs ignore or forget that there's a tradeoff here and just go for "install a package/library to do it" as if it were cost-free.
Minimizing the use of external code is not security theater at all. It's good practice. I think avoiding applications that use languages and platforms where lots of external code is common and expected is a reasonable thing. It's absolutely not a complete security solution, but it does reduce the risk.
