DevOps Vs. DevSecOps; Are They Headed in Opposite Directions?

August 14, 2018 Anat Richter

DevOps vs. DevSecOps

What do DevOps and DevSecOps — two unions of different divisions within an organization with the intention of rushing to the aid of agility and fast innovation— have in common with one another and what are the relationships between these development models? Are they both indicative of a trend that favors the multidisciplinary and the collaborative in software development? Or are they two separate forces pulling in opposite directions, offering contending modalities of software creation?

Did the rise of the DevOps movement with its pursuit of rapid innovation increase security risks, thereby inadvertently generating a need for DevSecOps? Or was the integration of security into DevOps simply born out of a desire to take security matters out of the sole custody of security practitioners and make it part of developers’ native experience and expertise?

We’re here to answer these loaded questions and separate fact from fiction in the DevOps vVs. DevSecOps evolution.

Arriving at DevOps

Lets begin with a swift stroll down memory lane, when the market demand for fast innovation leads to the rise of DevOps, a team of developers and operations personnel who were tasked with the job of automating once manually-done processes such as component selection, integration, configuration and provisioning, compliance management, backup processes, asset tracking, deployment and post-release monitoring, to name a few. In an effort to keep the production pipeline moving at all times, DevOps teams became the gatekeepers and janitors of all automation in application development.

The formation of DevOps teams did well to heal the historic divide between development and operations. In remedying this rivalry, DevOps was able to move away from previous models of software development, namely the waterfall model, with its siloed thinking and separation of labor whereby developers were responsible for producing code and operations maintained responsibility for its deployment and monitoring, resulting a multitude of bottlenecks, backlogs and all kinds of release setbacks.

Expectedly, DevOps caught on like wildfire. The industry was eager for a development model that could keep up with rising market demands and their ever shortening delivery requirements. With release timelines shortening from months to weeks and products at enterprise level releasing new versions as fast as a bi-weekly basis sometimes, it was clear that developers could not continue to be handle matters manually and remain agile. Something had to give. Operations, having always been more driven towards automation, were the solution. And so a new hybrid term was born that would automate development processes as well as operational tasks and gear the entire production system towards early detection of problems, fast response rates, little friction between departments, and, finally, no bottlenecks at the finish line.       

The Move to DevSecOps

If DevOps entails the automation and collaboration of development and operations processes, DevSecOps goes a step further calling for the adoption of security measures into the development process for the purpose of early and continuous risk management. It involves integrating security into the CI/CD pipeline, bridging the traditional gap between security and development teams.

And quite a gap it is. Because whereas the collaboration between Dev and Ops is a more  natural one, development and security teams have always had markedly contending objectives. Development is geared towards agile development and fast release, while security with its auditing and flagging practices, backtracks by nature inadvertently holding back development.

So what was DevOps to do with these security teams that were slowing it down?
Incorporate them, that’s what.
And why should security teams willingly comply?
Because if you can’t beat them, join them. It’s that simple.
Because without being part of DevOps, security loses transparency of the production cycle, and it cannot secure what it is not able to see.
And so was born a three-way hybrid called DevSecOps which inserts security into the DevOps team, and hands over responsibility for the automation of security tools and their integration into the SDLC.
Once in the hands of security professional, rather than DevOps teams who’s training is rooted in code writing, security personnel would feel more at ease to turn over security responsibilities to DevOps. A win win.
As Elizabeth Lawler, vice-president of DevOps security at CyberArk, notes “by their very nature, developers aren’t security practitioners. They are responsible for features and functionality, not figuring out how to manage credential collaboration and security for key assets.”

This is, in essence, the greatness and the newness of this odd amalgam called DevSecOps.
It is precisely the understanding that software development is going in the direction of DevOps at an increasing speed and security cannot remain a separate and insular entity.
If it is not shifted left, entering the SDLC at its earliest stages, then security will forever remain a hindrance, a nuisance, to agile development.  

Confounding Security with DevOps                                                 

So are DevOps and DevSecOps headed in opposite directions? The answer is a resounding no. In fact, at the rate application development is going DevOps will soon not be able to stand alone and DevSecOps will be forced to take its place.

DevOps vs. DevSecOps does not exist. The two don’t contradict, they are simply one generation apart. What DevOps was a few years ago, is what DevSecOps is these days. That buzzy term on the tongues of industry movers and shakers, not yet adopted by most but on the minds of many. Making security an integral part of the development workflow is not a change in tune, therefore. It is a mere advancement.

In months to come, as the adoption of DevSecOps becomes more widespread, it will be interesting to see how security tools become increasingly more actionable for developers; those DevOps teams expected to respond to automated security measures.

Previous Article
Zombies: Top 5 Open Source Vulnerabilities That Refuse To Die
Zombies: Top 5 Open Source Vulnerabilities That Refuse To Die

Next Article
Top 5 New Open Source Security Vulnerabilities in July 2018
Top 5 New Open Source Security Vulnerabilities in July 2018