There’s been a lot of talk lately in security and development circles about the need to shift left in the software development lifecycle—and rightly so. By bringing security into the picture from the beginning, you can catch weak designs and bugs earlier, when they’re cheaper and easier to fix. So far, so good. But does this mean you should forget about the right side of the lifecycle, when you have a production environment where applications actually get used by customers and compromised by attackers? The reality is, you can’t just “shift” security in one direction. To protect their applications and users, forward-thinking companies need to modernize security programs to both get involved in architecture and development earlier, as well as gain better visibility and defense capabilities for applications and APIs in production.
What have we learned from DevOps?
First and foremost, for development teams going through a journey to DevOps, “shifting right” is hardly a novel idea. We’ve already seen a similar shift-left, shift-right pattern in performance and testing. Initially, testing (including general quality and performance) followed only after applications had been almost fully written. When this proved inefficient, it was shifted earlier in the lifecycle to support continuous integration. Eventually, organizations realized the value of also shifting quality coverage right and giving developers visibility into the way code and services behaved live. They began using application performance management (APM) tools such as Datadog, App Dynamics, and New Relic to provide rapid feedback from production directly to development and DevOps teams. This approach exemplified what became one of the core tenets of DevOps: bringing previously siloed capabilities (in this case visibility into the performance of an application in production) directly back to the full teams so they could iterate faster.
The same principle applies in security and can be used to successfully modernize security programs. Just as operational visibility helps development teams discover and fix performance and quality problems faster; if you apply these same lessons to security, you can achieve similar benefits.
What shifting right can accomplish
As DevOps has shown, bringing previously siloed capabilities close to the development team is a great way to foster agility and accelerate modernization. Security has been late to this transformation, but on the plus side, this means that it can make use of lessons that were painfully learned by other facets of engineering during their own journeys. For example, in the past, performance was handled entirely by separate teams with their own dedicated tooling and jargon. The rise of DevOps shifted this siloed approach and brought tooling to the development teams so they could better manage the performance of their applications and services, allowing them to discover and fix issues whenever they arose.
DevSecOps applies this same lesson to security by providing visibility into how applications are attacked and abused. With this transparency, teams can discover and fix security issues more quickly when they arise.
Obviously, unifying security with DevOps is a journey, requiring developers, operations engineers, and security professionals to learn how to instrument applications for application-specific misuse and abuse. Beyond the visibility and protection a DevSecOps approach makes possible, it also enables organizations to share security responsibility more broadly—a step most developers welcome. In fact, a recently published DevSecOps Community Survey found that developers continue to believe security is important, but nearly half of them said they didn’t have enough time to focus on it. At a time when one in three successful breaches target web apps, giving engineering teams a practical way to contribute to the security of their applications can have a transformative impact.
Finding the right place for security in the development lifecycle
Shifting left has been a necessary and beneficial change for security teams, helping broaden their perspective beyond a narrow focus on penetration testing and static/dynamic analysis performed only after applications were almost entirely written. But it’s important to recognize that testing earlier is just one piece of security modernization, and adapting the other side of the lifecycle (“shifting right”) is just as critical. It’s time for security professionals to both “shift left” by moving testing earlier in the development cycle, and “shift right” by obtaining visibility into how applications and APIs are attacked and abused in production. Only if you modernize your approach to security across the full spectrum of application development, will you be able to break down traditional silos and bring security capabilities directly to the people managing development and DevOps teams as well as security teams.
