Is It Secure to Use Open-Source Code to Develop Fintech Apps?

April 13, 2023 - TuxCare PR Team

Fintech applications require a particularly strong security posture. After all, you’re safeguarding the financial data (or even more disconcerting – the money) of your customers.

Financial services providers are a lucrative target for hackers and successful attacks involve great risks for users and the organizations that own and run fintech apps. Should fintech developers, therefore, use non-commercial, open-source code?

It’s an “open” question and, in this article, we’ll discuss the risks – including what fintech developers can do to secure open-source code.

Tough security challenges for Fintech software development

Fintech applications have particularly tough cybersecurity requirements because of the high stakes involved. Common cybersecurity risks and challenges in fintech include cloud computing issues, malware attacks, third-party access, system complexity and compatibility, money laundering risks, identity theft and authentication, and – critically – compliance.

For example, to ensure security around electronic payments, the Payment Services Directive (PSD2) is enforced by many jurisdictions – with specific regulations on keeping data secure. In the USA, the Payment Card Industry Data Security Standard (PCI DSS) is responsible for regulating the collection, processing, and use of data for payment cards – but it’s a standard applied around the world.

So, not only are fintech apps at risk of cyberattack, they’re also in danger of non-compliance. A security failure can quickly have big consequences. Is it therefore a good idea to rely on “free” code?

What keeps data secure: open source or commercial code?

It’s a hot debate and the right answer is not that paid-for, commercial code is more secure simply because money is exchanged in return for application code.

Open-source code is more open to scrutiny because everyone can look at it. So, in theory, it’s more likely that a bug in open-source code will be discovered. On the other hand, there is no guarantee that the right people are looking critically at open-source code or that developers are motivated to find flaws. In fact, it may be threat actors looking for flaws.

Yet closed-source commercial software driven by profit may not necessarily be more secure, as vendors may not deploy security researchers to examine the code for flaws and may rush through coding to meet deadlines.

Ultimately, developers make mistakes regardless of whether they are paid or not, and it is important for both open-source and closed-source software to be reviewed and tested for security. For developers, that means that both code bases must be treated with the same caution.

Open-source security is a concern for everyone

But here’s the interesting part: commercial code commonly relies on open-source code components so organizations are likely using open-source code in their applications even if they rely mostly on commercial partners.

In essence, there’s a proliferation of open-source libraries and packages. In cloud-based applications, multiple open-source libraries and services are typically integrated into the tech stack, enabling developers to benefit from existing work.

However, in some instances, it also provides attackers with a gateway to breach networks. These open-source components may harbor vulnerabilities that can seep into production, leading to project delays if identified late in the build process or after deployment.

It’s an intricate situation with dependencies of dependencies that poses a distinct threat because it can be easy to overlook when an application invokes a package containing vulnerabilities. Either way, open-source vulnerabilities are part of the fintech development process, whether developers mainly rely on commercial code or open-source code.

Focus on DevSecOps to achieve security

Modern software development requires a continuous security process, not a one-time solution, and it doesn’t matter whether the code base is commercial or open source. This approach, known as DevSecOps, involves shared responsibility for security between development, security, and operations teams.

Threat modeling, security testing tools, penetration testing, and audits are all incorporated into the CI/CD pipeline. Developers can also use software composition analysis to monitor open-source components throughout the development process – and to watch for known major flaws that make it hard to keep data secure. This collaborative approach leads to faster, more secure software delivery for fintech apps.

All the other good advice is, of course, also valid: consistently apply good practices such as MFA, strong passwords, credentials management, and tight permissions. Monitoring and testing can also identify intruders and flaws. Understand the tools and underlying building blocks you rely on, including libraries and dependencies.

Arguably the most crucial element of software security is patching. Comprehensive patching protects against known vulnerabilities, whether using free or commercial software. But patching consistently is challenging and time-consuming, often resulting in only the highest priority vulnerabilities being addressed.

What’s more, patching may require a restart or reboot, and development teams may delay or avoid patching to maintain availability. Live patching is worth considering as a solution.

Conclusion

The question isn’t so much whether it’s secure to use open-source code in fintech apps, or not. Open-source code is everywhere and will probably find its way into your fintech application anyway. Should you use a bit more or a bit less open-source code? That’s another question – but you can’t really construct an argument that open-source code is inherently less safe.

Instead, focus on securing all code – including the open-source code you choose to use, and the open-source code that’s inside your tech stack anyway.

Summary