The Evolution from Waterfall to DevOps to DevSecOps and Continuous Security

Friday, November 03, 2017

Jonathan Bregman

B5e8617f76698eb78f0101a3db9326ae

Software development started with the Waterfall model, proposed in 1956, where the process was pre-planned, set in stone, with a phase for every step. Everything was predictably…sluggish. Every organization involved in developing web applications was siloed, and had its own priorities and processes. A common situation involved development teams with their own timelines, but quality assurance teams had to test another app, and operations hadn’t been notified in time to build out the infrastructure needed. Not to mention, security felt that they weren’t taken seriously. Fixing a bug that was made early in the application lifecycle was painful, because testing was much later in the process. Repeatedly, the end product did not address the business’s needs because the requirements changed, or the need for the product itself was long gone.

The Agile Manifesto

After give or take 45 years of this inadequacy, in 2001, the Agilemanifesto emerged. This revolutionary model advocated for adaptive planning, evolutionary development, early delivery, continuous improvement, and encouraged rapid and flexible response to change. Agile adoption increased and therefore sped up the software development process embracing smaller release cycles and cross-functional teams. This meant that stakeholders could navigate and course correct projects earlier in the cycle. Applications began to be released on time with translated to addressing immediate business needs.

The DevOps Culture

With this increased agile adoption from development and testing teams, operations now became the holdup. The remedy was to bring agility to operations and infrastructure, resulting in DevOps. The DevOps culture brought together all participants involved resulting in faster builds and deployments. Operations began building automated infrastructure, enabling developers to move significantly faster. DevOps led to the evolution of Continuous Integration/Continuous Delivery (CI/CD), basing the application development process around an automation toolchain. To convey this shift, organizations advanced from deploying a production application once annually to deploying production changes hundreds of time daily.

Security as a DevOps Afterthought

Although many processes had been automated with DevOps thus far, some functions had been ignored. A substantial piece that is not automated, but is increasingly critical to an organization’s very survival, is security. Security is one of the most challenging parts of application development. Standard testing doesn’t always catch vulnerabilities, and many times someone has to wake up at three in the morning to fix that critical SQL Injection vulnerability. Security is often perceived as being behind the times – and more commonly blamed for stalling the pace of development. Teams feel that security is a barrier to continuous deployment because of the manual testing and configuration halting automated deployments.  

As the Puppet State of DevOps report aptly states:

All too often, we tack on security testing at the end of the delivery process. This typically means we discover significant problems, that are very expensive and painful to fix once development is complete, which could have been avoided altogether if security experts had worked with delivery teams throughout the delivery process”

Birth of DevSecOps

The next iteration in this evolution of DevOps was integrating security into the process – with DevSecOps. DevSecOps essentially incorporates security into the CI/CD process, removing manual testing and configuration and enabling continuous deployments. As organizations move toward DevSecOps, there are substantial modifications they are encouraged to undergo to be successful. Instilling security into DevOps demands cultural and technical changes. Security teams must be included in the development lifecycle starting day one. Security stakeholders should be integrated right from planning to being involved with each step. They need to work closely with development, testing, and quality assurance teams to discover and address security risks, software vulnerabilities and mitigate them. Culturally, security should become accustom to rapid change and adapting to new methods to enable continuous deployment. There needs to be a happy medium to result in rapid and secure application deployments.

Security Automation is the Key

A critical measure moving toward DevSecOps is removing manual testing and configuration. Security should be automated and driven by testing. Security teams should automate their testing and integrate them into the overall CI/CD chain. However, based on each individual application, it’s not uncommon for some tests to be manual – but the overall portion can and should be automated. Especially tests that ensure applications satisfy certain defined baseline security needs. Security should be a priority from development to pre-production and should be automated, repeatable and consistent. When done correctly, responding to security vulnerabilities becomes much more trivial each step of the way which inherently reduces time taken to fix and mitigate flaws.

Continuous Security Beyond Deployment

Continuous security does not stop once an application is deployed. Continuous monitoring and incident response processes should be incorporated as well. The automation of monitoring and the ability to respond quickly to events is a fundamental piece toward achieving DevSecOps. Security is more important today than ever before. History shows that any security breach event can be catastrophic for both customers, end users and organizations themselves. With more services going online and hosted in the cloud or elsewhere the threat landscape is growing at an exponential rate. The more software written inherently results in more security flaws and more attack surface. Incorporating security into the daily workflow of engineering teams and ensuring that vulnerabilities are fixed or mitigated much ahead of production is critical to the success of any product and business today.

About the author: Jonathan Bregman is a Product Marketing Manager with Barracuda Networks focused on web application firewalls and DDoS prevention for customers. Prior to Barracuda, Jonathan was a research and development engineer with Google.

Possibly Related Articles:
13291
Firewalls Enterprise Security Policy Webappsec->General
Incident Response Monitoring Security application development
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.