How do you ensure external dependencies aren't a security risk?

Question

We use quite a few external open source libraries in our projects, pulled in from Maven Central etc.

I was wondering what is best practice to ensuring that you don't introduce some sort of security risk by using these dependencies. We have quite a few and it's unrealistic to re-write these libraries.

I'm not sure that it's relevant but I'm specifically talking about mobile development - IOS and Android apps

Answer 1

Both frameworks and libraries you use have vulnerabilities. Some of those vulnerabilities can be exploited to gain unauthorized access to your application/server/resources.

This fact, however, doesn't mean that you should throw them away and develop a standalone product which has no dependencies.

The question you should be asking is not if you introduce a security risk by using a dependency, but rather if you're able to replace a dependency by an in-house solution that is more secure than the dependency.

• In most cases, the answer is nearly obvious.

  If you're thinking about libraries and frameworks developed by reputed companies over the years, or about the ones created by large open source communities, chances are you can hardly beat them in terms of security with an in-house solution. Their code is thoroughly tested, code reviewed and regularly patched.

  I said “nearly obvious,” because there is one thing you can oppose to those libraries: lots of people look at the ways to exploit them, and zero day vulnerabilities could have a huge impact on all applications which use those libraries. Your in-house, probably closed-source solution, is probably not that interesting to an attacker, and is more obscure. This gives you an impression of a slight benefit; however, security by obscurity is a well-known anti-pattern, and if obscurity is the only thing between your code and the attacker, you're in a big trouble.

• Sometimes, it's more complicated.

  If you're thinking about libraries which don't have much attention or support, then there are chances you can do better if the library deals with your domain of expertise. Being able to see the source code can be very helpful there, and showing the source to a security expert is the best way you can have a good understanding of the risk level associated with the usage of the library.

  If it appears that the library contains possible (or obvious) vulnerabilities, you can either decide to rewrite it from scratch if the library is abandoned or is closed-source or contribute to the library to solve the vulnerabilities you notice otherwise. Developers often forget about this second solution, while it is usually the cheapest one and benefits not only you, but the entire community.