[bennyelv]

Neither of those is the right answer! I'm dealing with the fallout of 10 years of "add whatever you want", and it's a unsolvable problem given the state of the system.

The answer is devops:

You build your system in a way that it's nearly effortless to test and deploy, then you can upgrade your dependency tree continually with minimal effort.

[candiddevmike]

The problem is adding/changing a dependency should be a big deal: there should be validation and risk assessments performed against it, and this process should happen every time the library is updated. This isn't fun to do, and is a serious time sink, so it becomes a deterrent every time you want to update a library.

[jjav]

> adding/changing a dependency should be a big deal

This! In hindsight, I miss the days when adding just a single third party library took months of engineering and legal reviews and executive approvals. It forced us to be careful and only request external libraries when absolutely needed (and then think twice again).

Imagine going to your security team and saying that you'll walk out to the street, stop random people and the first one who claims they know how to program, you'll allow them to commit a bunch of code, with zero review, into your production codebase.

Nobody would allow that!

But we allow what is in reality the exact same thing by pulling in hundreds (if not thousands) of external dependencies without any clue what they do or if the code is any good. All if running in your production systems handling customer data.

[bennyelv]

Fair point - it should do. However if you've already accepted the risk that a 3rd party dependency might contain a vulnerability that has been undiscovered and you don't do any deep analysis of them, then you're still making your system more secure by at least getting the fixes for known vulnerabilities out of the door.