When it comes to software delivery, the waterfall model is the undeniable classic. Once the gold standard among developers, it has undoubtedly seen better days over its 50+ year history. But even as the world moved on, embracing the agile methodology and Infrastructure as Code (IaC), the legacy of the waterfall model lives on. And sadly, so do the security issues it was never designed to address.
Winston Royce has been generally credited with the development of the waterfall methodology in 1970, although the idea actually dates back to a publication in 1956 by Herbert D. Benington. Both authors rightly argued that one should not follow the software development steps one after the other. However, for decades, their pleas fell on deaf ears. In 1981, Barry Boehm published Software Engineering Economics and found that for each progressive phase of the waterfall model, the relative costs of development increased greatly, making security an afterthought that would too often be shoehorned into the testing phase.
One of the seminal works that attempted to improve the model was Microsoft’s Security Development Lifecycle (SDL), which proposed adding security to each phase of their modified waterfall model. Not surprisingly, SDL greatly increased the overall security of the software Microsoft released following this new model. And yet, too often security teams were not brought in to each phase and were instead kept out until the end for a final security review. More often than not, software was released with known and unknown vulnerabilities that would need to be fixed in later releases.
A new methodology for software development began to take shape with the release of the Agile Manifesto. This agile methodology mirrored the rise of successively interactive and responsive websites that would soon become web applications. The web applications would build on the exciting work of user experience researchers with the goal to be able to make changes multiple times per day, test features for a subset of users, perform live A/B testing and more. While attractive in its promise, however, this approach was only feasible for large, already established companies that had the resources and infrastructure needed for these experiments.
With the release of Amazon Web Services in 2006, the infrastructure finally caught up to these new exciting, agile workflows. AWS cloud services gave developers direct access to the infrastructure they needed to design, build and scale web applications from the ground up. At last, infrastructure could be provisioned programmatically and ephemerally, designed and deployed as code, scale to millions of users and provide the highly personalized web applications that users were demanding. This allowed for companies like Instagram to employ a mere 13 people while supporting a service with 30 million users.
Agile developer operations completely upended not only the waterfall model, but also the poorly integrated security processes. If we look at the roles and responsibilities of the mentioned 13 employees of Instagram, all of a sudden, security started to rely on everyone. Ironically, what once was postulated by Microsoft in their SDL for a waterfall model, began to permeate years later: security could no longer be a step in the development process. Instead, it needed to be tightly coupled at every phase.
The solution to this challenge started to formulate with the emergence of Infrastructure as Code. IaC enabled both software developers and IT infrastructure administrators to deploy applications infrastructure with known software best practices. Among other undeniable benefits of this approach, such as reduction in cost and increased speed of execution, IaC greatly reduced the risk of human error that would stem from common mistakes like misconfigurations. Another unexpected byproduct of IaC was the fact that developers became more involved in defining configuration, and conversely, operations teams got involved earlier in the development process. And just like that, IaC became an enabler for yet another milestone in software delivery – Developer Operations (DevOps).
How efficient can DevOps teams be? According to DORA’s State of DevOps report, high performing DevOps teams average over 1,400 deploys per year – a stark contrast with the 12 deploys per year typical of a low-performing group. With the mind-boggling scale of 1,400 deploys per year to worry about, these top-performing organizations were right to wonder: how do we incorporate security throughout the process? Similarly to the way the DevOps model emerged thanks to the joined forces of the Development and Operations team, a new model with the security layer in the middle started to gain traction.
By introducing the security layer, DevSecOps sought to remove the friction and toil associated with securing software in an IaC mindset. Some unique characteristic of the DevSecOps model included:
Standard software testing, audit, and scanning for security issues takes place throughout the development process, minimizing the need for disruptive and costly interventions late in the cycle
Vulnerability scanning and patching becomes an integral part of the release cycle, while automation and early discovery reduce the time required to patch vulnerabilities
Traceability, auditability, and visibility of the configurations and controls become the key pillars of the development process.
While relatively new – the term still does not have a dedicated Wikipedia entry – DevSecOps has been an overwhelming success among the practitioners and vendors alike, having been embraced by the likes of (ISC)², Microsoft, IBM, and even the U.S. Department of Defense. In its current iteration, we see DevSecOps as a maturing model with a maturing toolkit. This toolkit, also referred to as Security as Code, introduces a multi-step approach to providing transparency, repeatability and visibility into the checks and controls implemented by security teams. With pre-approved code, security testing, vulnerability testing, and the automatic enforcement of user and data access policies, Security as Code presents the latest – and perhaps the farthest – point in the journey that started with the waterfall model.
Without a doubt, it has been a long evolution for security in the world of software delivery. Had security been on the minds of the pioneer software developers before the late 80’s, it could have been much shorter. But the progress we’ve seen over the last few years gives hope that the best engineering minds of the present are on the right track. And while their journey is still far from over, the advancements such as Infrastructure as Code, DevSecOps and Security as Code are making a difference. In the world where the most life-critical organizations release new code hourly, there are finally reasons to feel optimistic that security can keep up with the pace.