The Perils of Outdated Dependencies

All software you develop will have some dependencies. Over the course of its lifetime, that number will grow and turn into an unmaintainable mess. As you approach this point, there is a tendency to not update dependencies frequently.

Let's dive into why this can be catastrophic and why you need to update your dependencies religiously, but meticulously.

Let's start off with the basics - what exactly is a "dependency"? Depending on what you're building, that can differ.

Generally speaking, it should be every bit of code that you didn't write - libraries, frameworks, software, tools, and even your operating system - and it's equally important to keep all of these up to date. All examples below can be extrapolated to each one. For this blog, however, we will talk specifically about libraries.

If it ain't broke, don't fix it#

A very common principle followed by many - when is the only time you've seen someone update a dependency? Most likely whenever your pipeline was broken - some vulnerability was found in one of the libraries and you need to update it ASAP!

These sort of updates are done on the pretext of "security", but honestly, the developer just wants a green build. The problem with these "reactive" updates are that you are not truly securing your application. You are only reacting after a vulnerability was found, and possibly already exploited on multiple systems. For all you know, you might have already been targetted.

If you host a service or library which has other consumers, you run the risk of propagating the vulnerability down the line. There's a possibility of carefully crafted inputs being able to exploit the same vulnerability.

Don't wait for a vulnerability to be reported to update your dependencies!

Proactive Dependency Updates#

Introducing "Proactive Dependency Updates" - where you don't wait for a vulnerability, or some quarterly bulk of updates to be done at once. Instead, you update a dependency as soon as an update is available.

Why is this necessary? A study by Mend found that over 90% of security issues, when discovered, were not present in the latest version of the library. This means that, more often than not, you won't get into a mess if you are on the latest version of a library.

Other than this, the incremental minimal updates enables you to quickly update dependencies when required in the future.

Imagine a scenario where you didn't update your dependency for a few years. You are sitting on v1.5.1 because there has been no issues with this version so far, whereas they have already reached v3.1.0. Suddenly, the owners of the library discover a critical vulnerability and release v3.1.1 to quickly patch it. They recommend all consumers to update immediately. Unfortunately for your team, it'll be a huge effort because of the breaking changes that came about in between, and every second you spend deployed on the older version is more time for attackers to discover and exploit your service.

By keeping your libraries up to date, you also get the added advantage of improved performance, new features and bug fixes from keeping your libraries up to date.

Alright, I'm going to automate dependency updation#

Hold up! You can't just dive in to automatically updating all your dependencies, there are some small risks involved in doing that. You need to update them meticulously.

For starters, you can't be sure your application will behave the same if you update. However, with a robust test suite, you can be more confident that your code won't break if you update.

The other issue is another security concern. How can you be sure that the newer version of the dependency is not malicious? It's not that uncommon that libraries get compromised. If you blindly updates dependencies, you are most certainly going to get pwned.

There is just one guideline to follow - know what you are updating, and if you don't, wait till someone who knows does so first. It's best to be very comfortable with all the dependencies you use, that way whenever some changes come in, you can assess whether the changes look malicious or legitimate. If you aren't that used to it, wait a day or two, to see if people discover something fishy with the newer version, and only then upgrade.

Confused? Follow this

How do I know when there's an update?#

There are various tools that assist in this. Your mileage may vary, and the same tools might not be best for you. It's best to explore and find the best Software Composition Analysis (SCA) tool that has this feature - Dependabot, Mend, Snyk and the list goes on. If you are already using an SCA tool but not enabled dependency updates on it - do it today!

So next time you see a newer version available for one of your dependencies, assess the changes and update it as soon as you can, and make sure everyone on your team does as well!

Till the next post, hasta luego!