Before you invest in dependency vulnerabilities

We end up explaining this on discovery calls often enough that it deserved writing down. Before you spend anything on dependency vulnerabilities, it is worth confirming a few things are already true.

The cheapest security work is the boring kind done on a schedule. If two people in the business would answer this differently, that gap is the actual problem.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• Your code is a small part of what you ship
• You have a way to tell whether it worked

Where it usually goes wrong

Automated alerts catch what manual review never will. The reasoning matters more than the rule, because the rule has exceptions. If it only works because one person remembers to do something, it does not work yet.

Fewer dependencies is a security strategy. Where this goes wrong is almost never a lack of knowledge. Write the reasoning down alongside the decision, because the reasoning is what changes first.

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
• Automated alerts catch what manual review never will — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.