Upgrading Third-Party Libraries and Software

Good patching practices

When defending ourselves against the risks implicit in third-party libraries, we need to know what third-party software we use. It takes a surprisingly large amount of effort to discover this.

Once we know what’s in use, we need the ability to quickly upgrade any of the third-party libraries and any software deployed in our organization.

What’s more, we need to be able to test these upgrades so that we can be confident that the upgrade won’t break anything.

We’ll want to automate this as much as possible because we need to do it often, and we need to do it correctly. Infrequently done manual upgrades are unlikely to work when under extreme stress and at the hurried pace likely to accompany a critical, newly discovered vulnerability. Finally, we need to be able to do it on short notice because we don’t know when we’ll need to upgrade.

Dependencies need to be current

In order to be ready to upgrade, we need to be relatively current with our dependencies. We can’t remain on old, unsupported versions of software, even if the old versions are functionally sufficient.

Being out-of-date is likely to cause trouble when a vulnerability is found. If we’re a couple of years out-of-date on a library and a vulnerability is announced in that library, we risk that the fix for that vulnerability will only be available in the latest version of the library.

There could be breaking changes between our old, vulnerable version of that library and the current version. This puts us in a bad situation, where we’re unable to upgrade to a fixed version, even though we know there is a vulnerability in the version we’re using.

Looking ahead

We’ll start by looking at patching and then look at the impact of a real-life patching mistake. Then, we’ll take an inventory of three kinds of third-party software that we use libraries we build our software with, networked software listening on our network, and operating systems.

Inventory in hand, we’ll look at how to find published vulnerabilities in that software. We’ll wrap up the chapter by outlining the testing we’ll need to have in place in order to upgrade quickly.

                                                 Q U I Z