Software Development: From Waterfall to Continuous Security

The Evolution of Software Development: From Waterfall to Continuous Security

Early software development followed the waterfall model, a term coined in the 1970s.  In the waterfall model, the software development process was pre-planned, set in stone, with a separate phase for every step. Predictably, this made the process sluggish.

Every team involved in developing a software application was siloed and had its own priorities and processes to follow. For example, it was common for a development team to have their own timelines, only to find out that the quality assurance team was busy testing another application, and operations hadn’t been notified in time to build out the necessary infrastructure. On top of that, security often felt they weren’t taken seriously.

 

In the waterfall model, fixing a bug that was made early in the application lifecycle was usually painful because testing happened much later in the process. After all of this, the organization was often left with an end product that did not address the business’s needs because the requirements changed or there was no longer a need for the product.

The Agile Revolution and DevOps Culture

After a few decades of everyone dealing with the inadequacies of the waterfall model, the Manifesto for Agile Software Development emerged in 2001. This model shook things up by encouraging adaptive planning, evolutionary development, early delivery, continuous improvement, and responding rapidly and flexibly to change. Adoption of this new approach increased, speeding up the software development process as organizations embraced smaller release cycles and cross-functional teams. This allowed stakeholders to course correct projects earlier in the lifecycle, and applications began to be released on time, which helped them to address immediate business needs.

As more development and testing teams adopted the agile methodology, operations became the holdup. The solution was to bring the agile approach to operations and infrastructure, resulting in the establishment of DevOps. DevOps culture brought together everyone involved, leading to faster builds and deployments. Operations teams started building automated infrastructure, which made it possible for developers to move much faster. This led to the introduction of continuous integration/continuous delivery (CI/CD), basing the application development process around an automation toolchain. Organizations shifted from deploying a production application once a year to deploying production changes hundreds of times a day.

Security as a DevOps Afterthought

Although DevOps has automated many processes, some functions have been ignored. For example, security is a significant part of the development process that is not automated, but it is increasingly critical. It can also be one of the most challenging aspects of application development. Standard testing doesn’t always catch vulnerabilities, which often means someone needs to wake up at 3 a.m. to fix a critical SQL injection vulnerability. DevOps teams often view security as a barrier to continuous deployment because manual testing and configuration halt automated deployments, slowing the pace of development.

As the Puppet State of DevOps report puts it: “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”

Or as Pete Cheslock put it ...

DevOps/SecOps and Continuous Security

The next stage in the evolution of DevOps integrated security into the process. DevOps/SecOps, also called DevSecOps, weaves security into the CI/CD process, eliminating manual testing and configuration and enabling continuous deployments. To be successful transitioning to DevOps/SecOps, need to embrace a few cultural and technical changes. Security teams need to be included in the development lifecycle from the beginning, and security stakeholders should be involved in every step along the way. This means working closely with development, testing, and quality assurance teams to discover and address security risks and software vulnerabilities and mitigate them. Security will also need to adjust to rapid change and adopt new methods to enable continuous deployment. Rapid and secure application deployments are possible when all the teams work together.

Removing manual testing and configuration is a critical part of the move to DevOps/SecOps. Security teams should automate their testing and integrate these tests into the overall CI/CD chain. While it’s common for some tests to remain manual, most security testing can and should be automated, particularly tests that ensure applications satisfy established baseline security needs. Security should be a priority from development to pre-production, and it should be automated, repeatable, and consistent. When handled properly, responding to security vulnerabilities becomes much easier along the way, which cuts down on the time it takes to fix and mitigate flaws.

The need for continuous security does not stop when an application is deployed. Continuous monitoring and incident response processes are necessary as well. Automated monitoring and the ability to respond quickly to events is a fundamental piece of DevOps/SecOps. As current events regularly demonstrate, any security breach can be catastrophic for customers, end users, and organizations. With more services hosted in the cloud, the attack surface is growing, and as more software is written it results in more potential security flaws. Incorporating security into the daily workflow of engineering teams and ensuring vulnerabilities are fixed or mitigated ahead of production is critical to the success of any business today.