Why we ‘shift-left’ with SecDevOps

Why we ‘shift-left’ with SecDevOps

How safe is my bank? With cybercrime on the rise, financial consumers are – rightfully – concerned about the security systems of the organizations they put their trust in. The way we build our core banking systems should reflect these concerns. In fact: we should always strive to be named amongst the most secure banks in the world.

Over the past years, we significantly changed the way our IT business operates. We now fully embrace the principles of agile working with DevOps. Product teams are fully responsible for both building and operating our digital platforms and applications. However, security remains a challenge when looking at how we allocate our resources. To begin with, every IT incident takes up valuable time of our software engineers that otherwise would have been used to improve our business.

Pre-production fixes are cheaper

Of course, our engineering teams are used to solve incidents when needed. No problem. But it breaks their flow of developing new features. So we are not creating customer value and therefore losing money. According to the research of the National Institute of Standards and Technology (NIST), the relative costs of software fixes post-production release are more than thirty (!) times as high compared to fixes implemented at an earlier stage.

This is why we have to ‘shift-left’. On the technical side of things, a lot can be said and written but it comes down to this: identifying potential problems early in the development path. Vulnerabilities found in pre-production environments (development, test, acceptation) can be solved without any negative impact on the banks’ customers and reputation. Short-cycled feedback also does not break the flow of development teams in their development sprints.

Improving our pipeline

We made the transition to DevOps. Now it is time to include security in our Continuous Integration and Continuous Delivery (CI/CD) pipeline. We call this SecDevOps, which includes several practices such as secure coding standards, logging and automation of controls. In a recent whitepaper for our IT professionals, we extensively explain how we build this pipeline. One of the most important messages is that to move from DevOps to SecDevOps, some effort must be made.

Automated checks in our pipeline are part of the solution, even though some activities such as pentesting still need human controls and intelligence. Equally important is building the right habits within our engineering teams. We focus on awareness with training to learn safe development patterns. We need to develop new skill sets in our teams, geared towards (data) security to enable them to solve problems effectively without breaking their flow.

Stable innovation

Our goal is clear enough: stable innovation, robust and ready for change. Our teams are highly motivated to deliver business value. SecDevOps built into our pipeline enables them to do so. We can deliver business value because we are stable. As we evolve from a business in financial services into a technology company, we should gear towards maximizing our potential to create digital value. This is why embracing SecDevOps makes so much sense: it is simply the next logical step in our digital journey.