5 reasons why developers at FinServ institutions are outpacing their security teammates

Advanced biometrics. Seamless onboarding walkthroughs. Cross-platform integrations. Hyper-personalized dashboards. Cleanly designed reports. 

These are just some of the features today’s users expect from their financial applications, pushing most financial institutions to release them quickly — or risk being outpaced by FinTech disruptors who already do. As a result, development teams must build more quickly, adopting new technologies to stay in step with demanding goals and tight deadlines. 

However, as developers at FinServ institutions quickly adopt new technologies and processes to match this speed of innovation, their security teammates often struggle to keep up. Many of them are attempting to apply older technologies to new development environments and unintentionally detract from the business’s bottom line. 

Why aren’t tried-and-true application security tools and processes working for these security teams? Let’s dive into a few of the realities of today’s FinServ development pipelines to find out. 

Infrastructure-as-code (IaC) is owned and provisioned by developers. 

Because many of today’s organizations host infrastructure within cloud-based IaC instead of hardware or data centers, it’s now a primary responsibility of the development team. The developers at financial services institutions are no exception. IaC is also prone to software vulnerabilities, which weren’t a concern when businesses hosted infrastructure on-premises. 

As a result, these developers’ security counterparts must include IaC in their application security initiatives. However, many older technologies don’t account for IaC and its possible attack vectors. 

Apps are hosted in complex, multi-cloud environments.

Each development team in a large financial services institution likely uses a slightly different pipeline with varied technologies and integrations. Each pipeline is a well-oiled, high-velocity machine. Usually, developers perform all their tasks within a designated integrated development environment (IDE), enabling them to get into a flow state as they assemble software.

The security teams responsible for securing this software respond to the multi-pipeline situation in one of two ways.

1. They try to create a “level playing field” between the different tech stacks by requiring all development teams to use the same security interface. However, the process is often frustrating to developers because it requires them to leave their state of flow and log onto a completely different platform.

2. They manually tune their security tooling to integrate into each specific pipeline. But, this can become overwhelming for the security team, as they must do this manual work for every development pipeline at their organization. 

Often, legacy tools only enable security teams to choose from these two options, as they weren’t built to easily accommodate the complexity and diversity of cloud-based development workflows. 

Microservices architecture is commonplace.

It’s also common to see microservices architecture within fast-paced development pipelines. Again, these features help developers speed up their processes and deliver on high customer demand. However, it also brings additional security risks into the picture, such as container image vulnerabilities and overly permissive communication between containers. 

Traditional security tools often miss these new types of container vulnerabilities. They also cannot differentiate between what’s “normal” for microservices architecture and what points to security issues, causing false positives and overalerting. 

Automation plays an integral role in development.

Development teams trying to keep pace with FinTech disruptors also heavily rely on automation, such as CI/CD tooling, to deliver powerful financial features at scale. This reality has a few implications for security teams. For one thing, new risks arise because a flaw in one part of the CI/CD pipeline can compromise the whole process. For another, security tooling must keep pace with these automated steps. Manually driven tools and lengthy audits won’t work alongside these automated pipelines.

New levels of speed are achieved through generative AI.

Recently, we’ve also seen development pipelines pick up in speed because of AI coding assistants. Most developers lean heavily on these coding assistants, often trusting them to produce quality, safe code — even though they frequently don’t. They use these AI-powered tools to generate first-party code much faster than humans alone could build software.

As a result, legacy tooling designed to secure first-party code written by humans can’t keep up. It’s not designed to secure the sheer volume of code that AI coding assistants can generate.

New development practices require new approaches to security

When security teams at financial services institutions don’t have the right tools and processes, they’ll get left in the dust by the highly ambitious projects and fast-paced deadlines of their development counterparts. Instead of attempting to move forward with how things have been done, these application security teams need new approaches to securing their organization’s cutting-edge financial apps. 

To learn more about what this shift could look like for your security team, check out our guide to optimizing AppSec in the financial services sector.