Shift Left is Only Part of Secure Software Delivery in Financial Services

Originally published by Sysdig.

Written by Eric Carter, Sysdig and Effi Goldstein, Snyk.

The way we manage our money has changed dramatically. In little more than a decade, we’ve gone from branch-led services to feature-rich apps offering 24/7 access to our money. Open Banking is driving product innovation, fintechs are setting a new benchmark for customer-centric experiences, and AI is taking personalization to a new level. Financial services have never been so accessible and convenient.

This startling progress could not have happened without relatively recent advances in software development, delivery, and operations.

Among those advances are the adoption of DevOps practices, continuous integration and continuous deployment (CI/CD) pipelines, use of cloud technologies, and automating everything from infrastructure provisioning to testing and quality assurance. These advances enable FinServ developers to deliver software faster, and to think about security and compliance earlier in design and development to ship safer software.

What is “Shift Left” and why does it matter?

“Shift left” is a philosophy for addressing the pitfalls of traditional waterfall-style development. In waterfall, a number of IT teams work over the course of many weeks or months, culminating in a big and beautiful software release. Of course, people make mistakes, forget things, and maybe don’t communicate well with each other. When it turns out that application elements don’t interoperate well, the teams frantically attempt to fix what’s possible and jettison what isn’t, with a very serious deadline staring them in the face. Products inevitably ship late, still somewhat broken, and with security bolted on as an afterthought.

To shift left means to introduce security processes and tooling earlier into the design and development phases. Security should be just as critical as functionality and quality. It’s a great idea because discovering a critical, build-failing vulnerability in a critical dependency after you’ve built dozens of functionalities on top of it hurts a lot more than if it’s found before you build anything at all. Maybe fixing the problem is as simple as using a newer version of a dependency, but now you have to make sure everything you’ve customized still works as intended.

There are a number of forms of application security testing (AST) that aim to detect code-level issues early in the systems’ development life cycle (SDLC). Two common types of application security testing when shifting left are software composition analysis (SCA) and static application security testing (SAST). Put simply, SAST tests the custom code your developers write; SCA tests dependencies you include in code.

Assessing the security of modern applications requires both testing types. If you believe shift left means not only finding problems but also fixing them, then developer-friendly tooling is necessary. Exactly what that means can be subjective depending on developer workflows in the organization, but at the very least, developers need self-service, seamless integration into their existing CI/CD toolchains and actionable results. Because most developers aren’t security experts, security findings must prioritize the riskiest problems, point to the source of the issue, and provide contextualized fixes, rather than making the developer hunt for them on their own.

Augmenting AST with runtime intelligence

One challenge with doing a lot of early testing – especially security testing – is that the more you test, the more findings you discover. Unfortunately, some of the results will be false positives and others may be true positives that pose a relatively low risk. Development teams with a high degree of security expertise must sift through and vet findings to prioritize flaws that are severe and actionable, but such practitioners are in short supply and this type of work is tedious.

Addressing the pitfalls of security testing isn’t simple, and it involves gathering as much contextual information as possible to begin to reason about the risk associated with each finding, usually expressed by what exploitable code is actually exercised.

Reasoning about vulnerability risk is not easy. We try to rank the criticality of issues to decide on an action. We can split the problem into two parts:

1. The context of the vulnerability itself includes metrics of severity, like the CVSS score, and threat intelligence, like whether exploits are publicly available or attacks are prevalent in the wild. This information is readily available from scanning tools and third-party sources like NVD, MITRE, and CISA.
2. The afflicted asset’s environmental context, however, is specific to your application and your infrastructure. Only your organization can really fill this part in. For example, is the application and data subject to specific compliance standards like PCI-DSS and GDPR? Is the impacted application protected by mitigating security controls? Is it exposed to the internet? Does the vulnerable component even get used at all? This is difficult or impossible to know until the application is running in its intended production environment.

Shift left is a way forward for modern cybersecurity, but the approach can be vastly enriched by pulling in Runtime Insights. This helps to prioritize what to fix first, removes friction, saves cycles of numerous IT teams, and reduces your organization’s vulnerability risk.

For WorldPay, runtime context has proved invaluable in freeing up teams to concentrate on revenue-generating work. “If my team logs in and sees 500 vulnerabilities, they then think, ‘am I going to fix our vulnerability or am I going to spend my time developing something which creates some money?’” said Bernd Malmqvist, WorldPay’s Principal Container Platform Engineer. “Showing us what is important and how to fix it is key to reducing our risk.”

What happens after release?

The whole point of shift left is to release secure and compliant software faster, but what happens next? Your flawless, beautiful code is delighting your customers with its stunning feature set and impressive performance. Then, on some idle Friday afternoon, right before what should have been a long holiday weekend, you get hit with a horrendous zero-day that you could never have predicted even if you tried.

When that happens, you need to respond by quickly identifying all of the affected workloads running in your environment and prioritizing them for remediation. You may need to take those workloads offline to patch immediately, limit network access to them, or otherwise mitigate the problem if a patch is either unavailable or taking too long to deploy. The point is that in real life, shift left is only one part of a successful security program, and the protective, detective, and remediation activities for your production environments on the right are also critically important to your organization’s safety and success.

Conclusion

Shift left alone was never going to solve all security problems, but it does create foundations for reliable, fast, and secure software delivery pipelines. Security and development teams alike often suffer from a deluge of noise and few useful signals. What they really need are consistent and prescriptive ways to make sound decisions about risk. Gathering context from multiple sources through multiple layers of the stack, including runtime insights, substantially improves the quality of the information that DevSecOps teams receive from their tools and must act on.

Combining shift left and shield right best practices allows financial institutions to improve DevSecOps efficiency and accelerate software development without compromising security and compliance.

With developers able to spend less time on fixing minor vulnerabilities and maintaining compliance, they can focus on what they do best: building a better digital experience for customers.