A short guide to dependency vulnerabilities

Most teams know this matters. Fewer have decided who owns it. Everything we would tell a client about dependency vulnerabilities in the time it takes to drink a coffee.

The realistic threat for most small businesses is automated and opportunistic, not targeted. It rarely shows up as a line item, which is exactly why it slips.

What it costs to ignore

Your code is a small part of what you ship. The reasoning matters more than the rule, because the rule has exceptions. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

The practical version

Automated alerts catch what manual review never will. There is a version of this that is over-engineered, and it is worth avoiding. Budget a little time for it every quarter and it never becomes a project of its own.

Where it usually goes wrong

Fewer dependencies is a security strategy. The cost of getting this wrong is rarely visible on the day it happens. Write the reasoning down alongside the decision, because the reasoning is what changes first.

What this looks like day to day

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

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.