Security Culture: Vulnerable Dependencies

March 13, 2020

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


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:

  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.


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




Our Posts:

Deliver security your clients can trust

Excellent security for small companies to build a standards and audit ready cybersecurity program.
© 2019-2022 Jemurai. All rights reserved.
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram