Securing next-gen development: Lessons from Trust Bank and TASConnect

Today, the average application contains thousands of moving parts. Organizations deploy to multi-cloud environments with containers and microservices, using a combination of code written by internal teams, generated by AI, and curated by third parties. 

Security teams face a tall order in keeping these complex applications secure, especially given the increasing number of software supply chain attacks. They must find ways to integrate security within new standard practices, such as AI-generated code, while also considering development velocity and business success.  

Snyk had the opportunity to host a session at Black Hat Asia that dove into best practices for responding to these new complexities and challenges. This conversation featured two industry experts: Jerome Walter, CISO at Trust Bank Singapore, and Madhi Periannan, CTO at TASConnect Singapore.

Read on to learn about some of the speakers’ firsthand experiences meeting and overcoming the security challenges of next-generation software development. 

What is next-gen software development, and how does it affect AppSec? 

According to the speakers, “next-generation” software development tends to be characterized by three factors.

Complex architecture

The average application contains several architectural elements, such as microservices, and connects to numerous external libraries and SaaS platforms. Development teams build these applications with a rapid, agile approach. This complexity makes it more challenging for security teams to mitigate risk in today’s applications. Walter said, “Today’s software is composed of external libraries and interconnection with SaaS platforms that we don't fully control… so when you do software security, you need to master infrastructure and understand SaaS and third-party software.”

Rapidly emerging AI tooling

Today’s development teams also use generative AI tools such as GitHub Copilot and Google Gemini to produce code more quickly. While this velocity can benefit business agility, it also means that both secure and insecure code enter the pipeline at an unprecedented speed. 

Distribution across multiple cloud environments and geographic locations

In addition, next-generation software usually lives in a multi-cloud environment, with employees and customers from across the globe accessing it. Periannan says, “Today’s applications have to be deployed on multi-cloud and in multiple countries. So that's where the complexity comes in. So we need to have better tools in place to manage security across different geographical locations.”

Balancing people, processes, and tools for next-gen application security

Responding to these challenges ultimately takes a balance of the right people, processes, and tools. Part of this balance includes shared responsibility between the development and security teams — a DevSecOps approach. By empowering development teams to fix issues throughout these complex lifecycles, organizations can minimize the risk that makes its way into production. Walter and Periannan offered a few recommendations for building a culture of security ownership, including:

Taking a proactive versus reactive approach.

According to the speakers, security must be proactive rather than reactive. Walter explained that this approach is all about seeing security as a journey—not a one-day shift. He said that to start out on this proactive security journey, it’s best to begin by “deploying tools, like Snyk, that give immediate feedback and analysis.” 

These tools empower developers to fix issues by providing the right level of feedback and remediation guidance. In some cases, security takes more than just a patch release. So sometimes, it’s best for the developers to examine the architecture and redesign to mitigate the risk. Because they’re closest to the code, the development teams can implement the best possible fixes. 

This proactive approach ultimately fosters a better relationship between security and development teams as well. Periannan explained, “With the right tools and threat models, we are not in panic mode or facing a ‘firefighting’ situation, which is not the best experience for the developers.”

A few other ways to take a proactive approach include: 

• Using threat modeling to understand the potential impact of existing vulnerabilities and conduct better risk prioritization

• Identifying remediation methodologies for every point of the software development lifecycle

• Fostering a shift left culture that emphasizes security by design early in the pipeline

Starting with a developer-first mindset

Walter also emphasized the importance of making the developers’ jobs easier. He said,  “Developers spend an enormous amount of time on security operations: rotating passwords, implementing patches, etc, and we want to help them spend more time on business by automating part of the security hygiene."

A few ways to make developers’ lives easier include:

• Automating as many route tasks as possible, such as password rotation

• Giving the developers the information they need to succeed, such as periodic security training and remediation guidance

• Taking the time to prioritize risk accurately enables developers to focus on the fixes that matter most

A developer-first mindset also means directly addressing any friction between the development and security teams. Facilitating a better relationship between these teams starts by opening up a dialogue and truly getting to know the developers’ pain points, daily workflows, etc. It’s also important for the security team to prove that they care about the developers’ time and are actively working towards better approaches. One of these key approaches should be evolving AppSec to focus more on accurate risk prioritization with context and exploitability rather than just sending long lists of vulnerabilities to the developers.  

Measuring AppSec success in a complex software environment 

Another component of security success is tracking the proper measurements. Walter and Periannan recommended five places to start, including:

1. Security training implementation with tracking to ensure that everyone who plays a role in the SDLC successfully completes the training

2. Security testing coverage across all developer layers, such as first-party code, open source components, infrastructure-as-code, containers, etc., to show progress in covering more of the development functions across the entire pipeline

3. Critical/high vulnerability testing to gauge the organization’s success in reducing vulnerabilities over time

4. Time to patch/time to remediate to measure if the program has gotten more efficient over time

5. Number of security automation to prove that the security team is working towards a faster and more effective approach 

While these measurements are security-related, first and foremost, they can also tie back to business KPIs. These connections between security and business goals can be surprising, such as a case with one of Snyk’s customers in the finance industry. This organization wanted to increase Net Promoter Score (NPS) but leaned on Snyk’s security tooling to meet this goal. Because Snyk made the process of finding and fixing vulnerabilities more efficient, the team was able to deploy patches within shorter maintenance windows, leading to increased NPS.

Walter also explained, “Time to remediate is an important factor in our ability to deliver software. It's directly linked to the ability of your business to deliver new features as well. The more agile you are in your software development, the more agile you are in patching. If you can deploy a new feature by tomorrow, you can patch by tomorrow. Understanding that getting faster is in the interest of both security and the business is a very good way to have a friendly discussion as a business.”

Tune into the entire session from Black Hat Asia 

As organizations look to enhance their application security in the face of evolving cyber threats and technology advancements, they must focus on proactive and developer-friendly practices. According to the speakers, this approach starts with a few mindset shifts. 

First, teams must realize that it’s all about continuous security — not just completing best practices like threat modeling once but constantly performing and monitoring security controls over time. 

In addition, security teams should change how they think about developers’ relationships with security. Development teams often have the most innovative ideas and methods for remediating issues since they are closest to the code and other application components. 

To learn more about fostering a strong relationship between security and development teams in next-generation software development, listen to the session “Securing the Next-Gen Software Development: Challenges & Solutions.”