When we build software, we use lots of libraries that we didn’t write. They could be open source, they could be commercial, they could even be framework code provided by a big company as part of a platform.
In any case, we have lots of code running in, over, under and around the code we actually write. If there is a problem in any of that surrounding code, it can effect the security of the software we are writing.
It is important to realize that frameworks, stacks and operating systems represent very rich targets for attackers. As an attacker, if I can find a vulnerability in Jemurai.com’s code then I can attack Jemurai.com. But if I find a flaw in say Rails or Struts, then I can attack all the sites across the internet running Rails or Struts. That means my work applies across a lot more targets. So I’m going to spend some time on this. In addition, often that code is available and open source so I can create and analyze it in a test environment.
To avoid being exposed by dependencies, we need to do two things:
The second item is obvious, and we list a number of tools below that you can use to detect vulnerabilities in your dependencies. You may also want to watch mailing lists for major libraries that you use so that you know what is happening with security updates.
The first item is less obvious - and turns out to be challenging in practice. We need to update in general because you never know when you’re going to quickly need to do number 2 (childish giggle) and if you are not up-to-date that can be really hard.
What do I mean by that? If you are say a major version or two off of a library like Rails, JQuery or almost anything else, you have to expect a certain amount of drift in the signatures and methods you use to interact with that library. The more the signatures change, the more work it is to update from Verion 2.1 to Version 4.2. So we need to keep up to prevent ourselves from getting into a spot where we want to update by tomorrow but can’t for 3 weeks because there is so much migration work.