As we review in DevOps Exposed, research suggests that whereas 88% of UK businesses have either adopted a DevOps approach or plan to in the next couple of years, only 19% are fully confident in their ability to integrate security into this philosophy. This underlines the work that needs to be done in many organisations to embed and automate security best practice into the entire DevOps lifecycle.
That’s because companies appear to be exposing themselves to increased risk in their desire to remain agile. But, by introducing DevSecOps they can focus on reducing this risk by integrating continuous security improvement and testing throughout the entire development and operations lifecycle:
The continuous “infinity loops” of DevSecOps
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
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.
- 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.