Back to Blog

SecurityCulture: Vulnerable Dependencies

Matt Konda Mar 13, 2020 4:09:20 PM
security culture vulnerable dependencies developer security

 

In the latest video of our Security Culture series we talk about software dependencies. You can also listen in on our podcast.

The Basic Problem

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.

A Rich Target

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.

Solution

To avoid being exposed by dependencies, we need to do two things:

  1. Update in general
  2. Detect and update in the case of a vulnerable dependency

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 Version 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.

Conclusion

  • Stay up to date in general.
  • Run tools to check your dependencies.
  • Integrate dependency checking tools into your CI/CD (automation) so that you have assurances that these checks are running.
  • Sign up for security mailing lists for major frameworks or platforms you use.

References

Tools:

OWASP:

Our Posts: