Fintech cybersecurity: How to build securely with open source

0 mins read

Why is cybersecurity important for fintech companies?

Financial transactions are a natural target for hackers looking for an easy payday. For this reason, traditional banks are governed by strict cybersecurity regulations. Financial technology (fintech) companies however, are not as strictly regulated as banks, and they often skip key steps in the security process, especially when there is no clear requirement to fully secure applications.

But fintech companies should consider cybersecurity their top priority for a few reasons:

Types of data stored

Since fintech companies handle the same types of financial data as banks, they are an attractive target for attackers. This sensitive data includes account information, account balances, information about cash flows, budgets, and contact information.

Given the value of this data, particularly for mining using AI/ML projects, Fintech companies have an incentive to store as much specific and useful data as possible. There’s a tradeoff, however, as storing large volumes of data makes them a more valuable target.

Cost of breaches

For traditional banks, the cost of a breach includes both direct costs and indirect costs like reputation damage and fines. A single breach could also drive thousands of customers away. Since fintech companies deal with the same type of data as banks, a breach can have a similar negative impact. Loss of customer trust and reputational damage may be the most costly aspect of a breach, especially for fintech startups or companies that are experiencing hypergrowth. Breaches may also have legal consequences in the form of fines and lawsuits.

Compliance

It’s a fintech company’s obligation to follow Know Your Customer (KYC) as well as local regulations for any region in which customers are located. These regulations include:

For the EU:General Data Protection Regulation (GDPR) regulates the processing of personal data for individuals residing in the EU, even if the organization is outside the EU. Electronic Identification and Trust Services (eIDAS) governs cross-border digital transactions and provides a unified framework for Fintech companies, customer organizations, regulatory authorities, and end users. Payment Services Directive (PSD2) stipulates security around electronic payments. PSD2 often overlaps with GDPR, so may require expert consultations to ensure compliance.
For the USA: Payment Card Industry Data Security Standard (PCI DSS), which regulates the collection, processing, and use of data for the major credit cards.
For the state of California: The California Consumer Privacy Act (CCPA) resembles GDPR but has a few differences, such as around definitions of legal terms. Fintech data aggregator Yodlee faced a class-action lawsuit after allegedly violating CCPA with its data collection and use practices.

What challenges do fintechs face around cybersecurity?

Cybersecurity needs to be a top priority for fintechs, but there are many roadblocks to properly securing applications. Cybersecurity has traditionally focused on securing the end product through passwords, encryption, multi-factor authentication, and secure logic. Responsibility for security fell into the hands of IT operations and security teams. Applications were mostly tested after release into the production environment, which left many organizations exposed. When a bug or vulnerability was discovered, security teams had to backtrack the application to developers.

Most companies now incorporate security testing pre-release as well. The problem with this is the potential for unplanned outcomes that lengthen the release cycle. How do you deal with dozens or potentially hundreds of vulnerabilities you may uncover? Remediating vulnerabilities could require significant rewrites of underlying software components, which would then need to be reverified and retested. Moreover, this creates friction between security teams and developers. Developers may ship insecure software to get a fintech product to market faster, but it becomes very expensive to fix issues later on in the software development lifecycle (SDLC).

In short, these traditional testing practices have become outdated. The types of vulnerabilities have evolved, and the way software is developed and delivered has changed. With market demands requiring fast delivery, mainstream application development uses an agile approach. This more modern DevOps approach to development includes splitting large monolithic releases into shorter sprints, releasing new features multiple times a day, faster iteration, and including automation wherever possible. Organizations using an agile approach find that legacy application security tools designed for the pre-cloud era become a bottleneck to fast, secure deployments.

What are the risks of open source for fintechs?

The proliferation of open source libraries and packages presents an additional challenge for fintech cybersecurity. Cloud applications typically integrate numerous open source libraries and services. This allows developers to leverage work others have already done, but it gives attackers an opening to breach networks.

These open source applications can contain vulnerabilities that can pass into production. When they’re caught at the end of the build process or in production, it ultimately leads to project delays.

Transitive dependencies (or dependencies of dependencies) present a unique risk, since they create a complex dependency tree. This makes it easy to overlook when your application calls a package with vulnerabilities. As open source usage continues to grow, modern fintech applications have a larger attack vector than just the proprietary code they develop.

How can a DevSecOps culture be applied to fintech?

The reality of modern software development means security needs to be a process, not a one-off solution. Security should be incorporated through the development lifecycle, using security testing tools, penetration testing, and audits.

This new approach to security, known as DevSecOps, is an extension of DevOps that introduces shared responsibility for security between development, security, and operations teams. Security and DevOps teams work together from the start to integrate security into the CI/CD pipeline. Threat modeling happens early and often. Developers use software composition analysis (SCA) throughout the process to monitor open source components.

Production features and applications become a result of a collaborative process. Security won’t have to go to development teams after the fact, since they’ll know security was built into the development process from the start. Integrating security into DevOps processes thus gives developers ownership over security. Since vulnerabilities and bugs are caught early, DevSecOps ultimately results in faster, more secure software delivery with reduced costs.

Transitioning from DevOps to DevSecOps is not the responsibility of developers alone. Security teams should oversee the planning process and focus on applying security with minimal disruption to existing workflows.

Adopting a secure-by-design mindset

DevSecOps seeks to make software secure-by-design. This begins in the early stages of development with software security, a proactive approach that focuses on preventing code issues like buffer overflows and improperly handled exceptions.

It’s critical to get these early stages of development right by setting up tools and procedures to find and fix bugs. Dependency chains of open sources libraries and packages are another key area, since they can become confusing and obscure application vulnerabilities.

Fast feedback loops help lower the incidence of bugs, and it’s important to select open source libraries according to secure-by-design principles.

Implementing shift left principles

A key aspect of security-by-design is shift left security, which incorporates application security measures from the start. Shifting left empowers developers to integrate security in existing workflows, while allowing security teams to support developers and provide oversight. It starts with defining security policies, then assessing the software creation process to find small steps you can take to test earlier. It’s critical to automate security and give teams constant visibility into the process.

Building a secure SDLC

A Secure SDLC complements a DevSecOps approach to software development. DevSecOps focuses on creating shared ownership over application security, while a secure SDLC focuses on incorporating security into the design and build process.

Securing the standard SDLC starts with a mindset shift in development teams. The focus shouldn’t be only on functionality, but also on security throughout the project. The goal is not to eliminate traditional checks, but to address potential issues from the start instead of trying to backtrack once the software is pushed into production.

Development teams lead security efforts, meaning the domain experts who write the software fix the issues. It seems like a lot of effort, but the majority is automated in a secure SDLC environment. The result is more secure applications in production at a lower cost.

How Snyk supports Fintech cybersecurity

Snyk Open Source is an SCA tool that detects vulnerabilities in dependencies as you code in IDE or CLI. The developer-friendly tool scans pull requests before merging and can block vulnerabilities from passing the build process. Snyk enables automated testing throughout your CI/CD, and continuously tests your applications for exposure to existing or newly uncovered vulnerabilities. Other features include continuous monitoring, customized security rules, and automated license compliance management.

As a fintech company dealing with sensitive, private information, Revolut must keep to specific standards. Snyk implementation ensures the company’s ability to protect the core infrastructure and maintain PCI compliance among others.

“We get audited all year long. By using Snyk, we can say we’ve secured our open source pipeline,” said Evangelos Deirmentzoglou. “So it’s not just about improving our security exposure but also supporting our compliance efforts."

Live Hack: Exploiting AI-Generated Code

Gain insights into best practices for utilizing generative AI coding tools securely in our upcoming live hacking session.

To learn more about using Open Source components in fintech, check out our on-demand webinar: Best Practices and Pitfalls for Using Open Source Components in Fintech

Fintech Cybersecurity FAQ

What is fintech?

Traditional banks are looking for ways to modernize and support their customers’ demands for innovative services. One avenue is to partner with fintech companies to deliver financial products like payment processors, small loan approval, and digital wealth management. Fintech companies are typically small but fast-growing startups, meaning they can deliver applications on faster release cycles than banks are capable of internally. By partnering with fintech companies, banks can respond to rapidly evolving market demands while retaining existing customers.

How can shifting left help secure Fintech?

Traditionally, cybersecurity focused on securing software in production using authentication or encryption. This resulted in vulnerabilities in live software, and created a headache for development teams when they had to backtrack and rework code. A more cost-efficient and effective way to secure software is with shift left security. Shifting left introduces security at the earliest stages of development, and combined with DevSecOps, incorporates checks at each step to ensure the application is fully secured when it’s released into production. The result is development teams have greater responsibility for security of their code, and ultimately the total cost of delivering secure software is lower.