It all started with the Waterfall model of software development. The development process was pre-planned, set in stone, with a phase for every step, everything was predictably… slow. Each organization involved in building a web application was siloed, and had its own priorities and processes. Development teams had their own timelines, but QA had to test another app, and ops had not been notified in time to build out the infrastructure you needed, and security felt that you weren’t taking them seriously. Fixing a bug that was created very early in the cycle was painful, since testing would not begin until much later. Frequently, the end product did not fit the business’s needs – ether because the requirements changed, or the need for the product itself went away.
After many years of this unsatisfactory situation, in 2001, the Agile manifesto emerged. As Agile adoption increased, it sped up the entire process of software development, with smaller release cycles & cross-functional teams. The cultural/process improvements and smaller release cycles mean that stakeholders could course correct much earlier in the cycle. They also mean that applications are released on time and solve immediate business needs.
As the development and testing teams adopted agile, increasingly, ops became a bottleneck. The way out was to make operations and infrastructure agile, leading to DevOps. DevOps brought together all the teams that were required to build and deploy faster. Operations teams started building out automated infrastructure, allowing developers to move much faster. DevOps led to the evolution of the Continuous Integration/Continuous Delivery (CI/CD), building the entire application development process around an automation toolchain. Organizations went from deploying a production application once a year to deploying production changes hundreds of times a day.
While a lot of the processes have been automated with DevOps so far, some functions have been ignored. A significant function that is not automated, but is increasingly critical to an organization’s very survival, is Security. Security is one of the more difficult parts of application development. Vulnerabilities aren’t always discovered by standard testing, and very often someone has to be woken up at 2AM to fix that critical SQL Injection vulnerability. Because of the nature of the function, security is often seen as being behind the times – and more often than not blamed for slowing down the pace of development. Typically, manual security testing and configuration is the blocker for teams who want to move to Continuous Deployment – completely automated deployments. As the Puppet report linked above 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, and which could have been avoided altogether if security experts had worked with delivery teams throughout the delivery process.”
Or as Pete Cheslock put it…
It is only natural that the next evolution of DevOps is the integration of Security into the process – with DevSecOps. DevSecOps integrates security into the CI/CD process, removing manual processes and enabling Continuous Deployments. As organizations mature towards DevSecOps, there are some significant changes that they should undergo to make the successful transition.
Injecting Security into DevOps requires some cultural and technical changes. Security teams should be part of the development cycle from Day One. Right from planning to being part of each iteration, and working closely with the development and testing/QA teams to identify the security risks, software vulnerabilities and mitigations. Culturally, security teams should look more towards enabling the application and adapting to rapid change. They should work with the other teams to find a happy medium to enable rapid& secure application deployments.
An important part of moving towards DevSecOps is the removal manual testing and configuration. Security should be automated and driven by testing. Security teams should automate their tests and hook them up into the CI/CD chain. Based on the risks and the actual application, some of the tests can end up being manual – but a significant portion can be automated – especially those that ensure that an application satisfies certain defined baseline security needs. Security testing should happen right from development to pre-production. It should be automated, repeatable and consistent. When this is done right, responding to security vulnerabilities becomes easier during each step of the process – reducing the time taken to fix or mitigate vulnerabilities.
Continuous security doesn’t end with the deployment of the application. Continuous monitoring and incident response should be part of the process. The automation of monitoring and the ability to respond quickly to incidents is an integral part of the move to DevSecOps.
Security is more important today than ever before. More and more services are online, hosted in the cloud and elsewhere, and any security issue can lead to catastrophic results – be it for the customer/end-user or the business itself. Integrating security into the daily workflow of engineering teams and ensuring that vulnerabilities are fixed or mitigated much ahead of production is critical to ensuring the success of any product and business.
- From Waterfall to DevOps to DevSecOps & Continuous Security - August 17, 2017
Comments are closed.