Five mistakes teams make with dependency vulnerabilities

It comes up on almost every project, usually later than it should. These are the ones we run into repeatedly when we audit dependency vulnerabilities.

The cheapest security work is the boring kind done on a schedule. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Your code is a small part of what you ship
• Automated alerts catch what manual review never will
• Never checking whether the fix actually worked

Fewer dependencies is a security strategy. Getting it slightly wrong is survivable. Ignoring it entirely is not. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Making it stick

How to tell if yours is fine

Security is a maintenance habit rather than a purchase, which is why it drifts. Three things worth confirming about dependency vulnerabilities before you move on:

• Someone can say what the current setup is without going to look
• Fewer dependencies is a security strategy — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.