I think the basic problem is that the ease of adding new dependencies means that dependencies are more frequently added without consideration. Delegating auditi

I think the basic problem is that the ease of adding new dependencies means that dependencies are more frequently added without consideration. Delegating auditing of dependencies to a specific individual on the team can solve that problem if that person is very conservative about what they allow, but that seems to no longer be the norm. It's not just security that this hurts: I've worked on a few projects now where one or two of the dependencies introduced early on later became the source of the majority of the work on the project. Often dependencies added to solve one problem are unable to solve other problems and are designed in such a way that they are tightly coupled to everything that uses them. The result: either you put in the time to rip out the dependency, or you pile workarounds on top of workarounds to the point that it would have been easier to write the dependency yourself. There is, of course, a balance to be had here: a solid library can save you an immense amount of work. But only a handful of the libraries I have used are actually solid, and I'm increasingly unwilling to pull in dependencies I haven't used before. As a rule of thumb: I never want to use a library that's not versioned 1.0 or higher. A 1.0 version doesn't mean that it's ready for use in production systems, but a 0.x version number has always meant it's not ready, in my experience.