How to get dependency vulnerabilities right
It comes up on almost every project, usually later than it should. The short answer to dependency vulnerabilities is that it is mostly a sequence of small decisions, not one big one.
Security is a maintenance habit rather than a purchase, which is why it drifts. The version that survives contact with a real deadline is the simple one.
What is actually at stake
Your code is a small part of what you ship. None of that requires a large budget, only a decision and someone to own it. The version that survives contact with a real deadline is the simple one.
The steps
- Establish what you have today before changing anything
- Automated alerts catch what manual review never will
- Fewer dependencies is a security strategy
- Write down the decision so the next person does not re-litigate it
Fewer dependencies is a security strategy. None of that requires a large budget, only a decision and someone to own it. Budget a little time for it every quarter and it never becomes a project of its own.
Where to go from here
In practice
The cheapest security work is the boring kind done on a schedule. 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
Worth checking on your own setup before it becomes someone else's problem to fix.