Every dependency is a vulnerability

2 min read Original article ↗

Not so long ago, we all got comfortable with the idea that great chunks of the programs we were writing should be implemented by libraries pulled in from third parties — using CPAN, Maven, NPM or what have you. It was the reuse we’d always dreamed of. Happy times, right?

Not so much, I now think.

Every dependency is a potential vulnerability, for several reasons:

  1. Security errors in the included code.
  2. Malicious security exploits in the included code.
  3. Weird behaviour on the part of included code’s maintainer.
  4. Deprecation of the included code, for example when the original maintainer just loses interest.
  5. The constant churn of new major versions that you have to follow if you want security updates.

And by far the worst problem:

  • Transitive dependencies

All the things that can go wrong with a library that you use can also go wrong with any of the libraries that it uses; or any of the libraries that they use; and so on, down the chain. Libraries using libraries using libraries is such a well-established pattern that adding one new direct dependency to your project can easily add hundreds of indirect dependencies — all of them vulnerable to security errors, malicious exploits, maintainer tantrums, deprecation and incompatible new releases.

For these reasons, I now think much more carefully before adding a dependency, and will sometimes err on the side of writing my own code rather than using someone else’s.

Obviously it’s not that simple. Sometimes my own code will have security vulnerabilities that I didn’t think of and that someone else’s battle-tested library has eliminated. But, looking at my list above of five reasons to beware of dependencies, it does look like that’s the only one that could be worse when I write it myself. I am not likely to inflict problems 2–5 on myself!

The other big factor of course is that it’s more work to roll my own code than to use someone else’s. But I do think that the time-saving advantages of re-use are sometimes oversold. The impedence-matching work of using libraries can often account for a fair proportion of the work of building the required subset from the ground up.

I don’t have a good answer to any of this. I just find myself souring on the re-use approach of a decade ago.

This entry was posted in Bad habits, Culture, Despair, Programming. Bookmark the permalink.