Dousing the dependency hell in fintech apps

One of the most important things you can do to make your fintech apps more secure is to let your developer team go beyond coding and get involved in security design and security operations including dependency and vulnerability management. I start with this idea every time I’m asked to give some advice on data security issues in fintech since this is especially important in building apps that operate funds as they require a higher security baseline. 

Unfortunately, it’s not an unusual thing in security engineers' life when we audit applications and find dozens (if not hundreds) of 3rd party libraries. These libraries make developer life’s easier, but many of them bring mistakes and security vulnerabilities to the app. 

For example, have a look at React Native, a popular cross-platform framework that allows developers to write mobile applications using JavaScript. React Native is often used for banking, finance and crypto wallet applications.

My colleagues analyzed several financial apps written on RN, and their open-source dependencies. As we work in data security, we paid extra attention to security and cryptography libraries.

Just check some figures. 12.6% of the examined cryptography libraries have known vulnerabilities. 17.2% look abandoned, 16.1% have more than 100 opened issues and no tests, while 2.3% have more than 500 unresolved issues.

It means that only half of the used libraries are “more or less” okay. And these are the security libraries we are talking about.

Vulnerable and outdated components are one of the top application security risks (check out OWASP Top10, OWASP ASVS, and OWASP MASVS). The dependency management process is only one small bit of software security. In my previous posts, I often explain data security and cryptography–another small bit.

Quick tips on how to choose a proper 3rd party library.

First of all, review and update all libraries your application is using right now, or configure an automated dependency management process.

Second, document your assets: libraries you use, why you use them, what are their licenses, etc.

And last but not least: tests. Do tests to verify the correctness of third-party dependency behaviour. Does the library actually implement what is claims? Is the behavior the same on iOS and Android? While this is definitely beyond coding, this is still the developers’ part of the app dev process.