The DevSecOps mindset: a quick guide to "shifting left and shifting right"

Below we highlight the need for many organisations to embed and automate security best practices into the DevOps lifecycle. By adopting DevSecOps, companies can mitigate risks while maintaining agility, focusing on continuous security improvement and testing throughout development and operations.

The continuous “infinity loops” of DevSecOps

image source: Gartner

Time for a rethink

With the need for speed it’s easy for businesses to fall into a high risk cybersecurity posture, often without even realising it. Yet, increasingly stringent regulations and higher resulting fines are forcing many to rethink their risk profile.

A main reason for any weakness in the process is because  DevOps teams are generally required to work within tight timescales, with a ‘sprint’ of a mere two weeks often being the norm. And any scope creep that causes this deadline to slip costs money and reduces their agility. This, ultimately, affects the business’ ability to compete and causes an inbuilt friction with security teams, who are often perceived as being tantamount to putting a restrictor on a sports car. 

Measure twice, cut once

Measure twice, cut once is a well known proverb in many physical industries such as carpentry, building, and engineering and it is particularly relevant for DevSecOps as well. As in all areas of commerce, retrofitting something costs significantly more than if you designed it properly in the outset. In fact, Microsoft found that it is ten times more expensive to retrofit security into a finished application than write it properly in the first place.

However, cutting before fully measuring is what has traditionally happened with DevOps, where security has only really been considered on the Ops side of the infinity loop. 

"Security testing needs to become agile during rapid phases of change."

Chasing waterfalls

In the old world of waterfall development strategy, you start with planning, then move into create, then verification, and then pre-production once the coding has been finished. It is only then that the DevOps team have undertaken some security testing. More often than not, they wait until the actual release phase. However, by then it is too late. An issue found then will have a huge impact on the go-live date. 
 
The only sectors to undertake security testing earlier on in the process historically have been retail and financial services; the latter because of stringent FSA regulations that demand that coding is tested at each stage to gain a digital certificate to progress to the next. 

Shifting left and right

You may have heard the term ‘shifting left’ in relation to DevSecOps before. What DevSecOps means in reality, though, is shifting left and shifting right. This is because checks need to be implemented at all stages of the DevOps cycle, be it planning, coding, pre-production, production, or even decommissioning.

To address this, security testing also needs to become agile and more closely integrated within the entire development process to ensure vulnerabilities don’t go unchecked during rapid phases of change. In other words, a continuous testing ethos is required. The good news is that not only can continuous security testing help meet compliance requirements, but it can actually prove to be a more efficient way of testing, as you only need to assess the parts that have been changed each time, not the entire code. 

"Everyone can start owning the security of their applications."

Agility is not an excuse

What this all points towards is the imperative need for a clear and logical strategy of security testing throughout the entire development cycle. Agility is not a reason for businesses to put security on the back burner. What’s more, in today’s global climate, compliance is a challenge that nearly every business faces. But it should not be thought of as a simple tick in a box. By implementing a continuous security testing culture throughout your DevOps cycle, you can improve your security posture and reduce the security debt associated with having to retrofit security onto apps too late in the DevOps process. 

To make all this happen, one of the guiding principles is close collaboration between different teams across the business. In the same way that Development and Operations teams were invited (sometimes pushed) into the same room, it’s now time for Security teams to join the party. And that requires a common understanding of what everyone is doing, and why. That way everyone can start owning the security of their applications in the same way they own quality, development, and operations.

Key takeaways:

• Increasingly stringent regulations and higher resulting fines are causing DevOps teams to rethink their risk profile.
• It is ten times more expensive to retrofit security into a finished application than write it properly in the first place.
• DevSecOps means shifting left and shifting right. This is because checks need to be implemented at all stages of the DevOps cycle.
• In order to successfully embed security into the DevOps process, security teams and developers must work together and establish shared responsibility.