From Waterfall to SecDevOps: The Evolution of Security Philosophy
In the beginning was the waterfall, a rigid, sequential model of software development based on the earlier heritage of manufacturing design and development. It took decades for waterfall development approaches to give way to the need for agility. That brought about the shift to DevOps, combining software development and operations into one ongoing process.
But even agility and DevOps soon ran into a problem. As in waterfall development, security tended to be bolted on as an afterthought, increasing development costs and, worse, introducing vulnerabilities.
Now a new philosophy, SecDevOps, is placing security at the forefront of the DevOps process. The fundamental principle behind SecDevOps is that security cannot be bolted on as an afterthought. It needs to be integral to both the development and operations cycles. When it is, software can be built with greater agility, delivered more rapidly and, most importantly, safer and more secure.
The Inflexible Waterfall Model
Although the term “waterfall” was first used to describe development in the 1970s, what is now called waterfall development dates back to the 1950s and the first generation of large software development projects.
According to Infosec Island, the waterfall model made development preplanned, sequential and sluggish. It was rooted in prior experience of manufacturing development projects. In those projects, such as the construction of aircraft, late-term changes in design were enormously expensive due to heavy investment in prototypes and production facilities. Hence the sequential process in which designs were approved before development began.
The waterfall model did not handle security very flexibly. But it hung on for decades because it was the only known way to approach large-scale engineering development, and it did help limit the number of costly late fixes.
The Agility Challenge
By the turn of the century, patience with the sluggish pace of waterfall development had run out and agility became the new watchword. Software programs, after all, are not designed or built like airplanes, with no metal bending involved and no inherent gulf between design and operations.
The demand for agility gave us DevOps. But when it came to security, the tendency to bolt on afterwards persisted. This ongoing problem provided the push and inspiration for SecDevOps, which has the goal of making security design as proactive as development and operations were supposed to be.
Embracing Built-In Security With SecDevOps
As a philosophy, SecDevOps comes with its own technological demands on security designers. Security deployments, like all deployments, must be continuous. Automated security testing is a necessity. Some specific key tests may still need to be manual, but most should be automated to keep up with the overall DevOps pace.
But the central SecDevOps principle is not new. Security embraces every aspect of software design and operation. Trying to bolt it on at the end is a sure way to guarantee a succession of complicated, costly and, ultimately, unreliable late fixes.
Conversely, the more fully security is integrated into the daily workflow of the DevOps team, the more thoroughly security will be built into the project from the outset. When you design for simplicity and robustness, security becomes a natural output, not a belated addition held in place by duct tape and wishful thinking.