The Origins and Future of DevSecOps (The New Era of Cybersecurity)

If you’re in the business of creating software, then you’ll already know and appreciate the importance of DevSecOps. As we’ll come onto shortly, DevSecOps is the software development journey’s latest iteration, and what a journey it’s been. As Einstein said, “If you want to know the future, look at the past.” If your organization is looking to transition to DevSecOps, then understanding that journey will help in many ways, not least with making better, more informed decisions. This blog post will look at the software development journey to now, which includes Waterfall, Agile, DevOps, Shift-left, DevSecOps, and what our crystal ball tells us the future holds.

Waterfall

Agile

That approach came about through Agile (or rather the Agile methodology or Agile methodologies). Unlike Waterfall, Agile factored in essential components such as requirements changes, close cooperation, communication, and an effective customer feedback loop.

Indeed, the first two principles of The Agile Manifesto are:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

To meet Continuous Integration and Continuous Delivery (CI/CD) expectations, Agile requires teams to work on multiple phases at the same, each with much shorter, concurrent deadlines (called sprints). This method allows the development and operations teams to see the current phase’s end goal and provides them with the flexibility to make changes, drive improvements, and improve the product. 

All sounds great except for one significant problem.

Dev, Ops, (and Security) were Siloed

Siloed to the extent that the left hand didn’t know what the right hand was doing. (Left being Dev and right being Ops. At this point, Sec doesn’t get a look-in and will remain ostracized for another six or seven years.)

Agile lived up to its name. As both software development and technology advancements and processes accelerated, some companies advanced to making multiple software releases/deployments per day. Unfortunately, Dev and Ops were tripping over each other’s bootlaces:

”It’s not my code; it’s your machines,” hailed Dev.

“It’s not my machines; it’s your code,” replied Ops.

The problem here was with Ops. Development teams were producing shippable increments, but Ops teams lacked the ability to process and ship them and this created an unavoidable and unacceptable bottleneck.

“You can’t pretend or deploy 10 times per day if you go down 10 times per day. That’s not being Agile, that’s being retarded.”

Fixing such problems was time intensive, and for CI/CD to happen, something had to give.

Dev and Ops merged to form DevOps

Sure, the speed of DevOps product creation was incredible. But security remained an afterthought stuck near the end of the lifecycle. By the time the product reached sec, security was lacking, bugs and vulnerabilities were rife, and all eyes were upon the sec team to stamp it approved. Granted, in some parallel universe, there might be some justification for pointing the finger of blame at sec, but the “Holy crapola!” sudden need for secure software was hardly a surprise.

No, DevOps always required security services and capabilities. But it was only as the DevOps pipeline/process became streamlined and more efficient that security moved to the forefront. DevOps teams needed to build security into desktop, cloud, and web applications, and security became less of a second-class citizen. (To be fair, the blame is not, and never is, all one-way. Both parties will benefit from less friction, but there must be some shared responsibility here.)

Regardless, major structural change was afoot.

The Shifting-left Security Paradigm

Around 2014/5, as the below image shows, three critical areas in the software development world were changing: the Center of Power, Architecture, and Security Paradigm.

The software security world was changing as developers became the new Center of Power. In the prime position, software dev speed accelerated, collaboration became more straightforward and better, and shipping software, in principle, was meant to become way faster. However, there was one tincy-wincy problem that they couldn’t work out how to overcome.

The security bottleneck

The security bottleneck was a long-standing lag and holdup near the end of the Software Development LifeCycle (SDLC).

Typically, security got the blame here. But, though security is an integral part of the process, the bottleneck was a burden and regarded as unacceptable. One solution broached was to shift security left and as close to dev as possible. 

Shift-left

We say ‘broached’ because Shift-left worked for some organizations but didn’t for many others. 

First introduced at the time of Waterfall, Shift-left’s idea was and still is, sound. However, organizations with monolithic or 3-tiered apps/tools—usually longer-standing and, arguably, more established enterprises—typically lacked the culture, flexibility, and even capability to achieve a viable Shift-left solution in any meaningful way. In contrast, newer organizations or those with more flexible roots could pivot much easier.

Security scanning tools

With organizations rapidly trying to Shift-left but lacking the culture, capability, and means to do so, many resorted to what they thought was the next best solution–heavy investment in security scanning tools. Unfortunately, this solution was flawed.

First, these scanning tools only highlighted how big their security problem was. Second, already overwhelmed security teams became further inundated with reports of security vulnerabilities that they were powerless to affect. Lacking the knowledge, security capabilities, or resources to deal with this volume of noise, false alarms, false positives, etc., only added to the problem. A problem that moved security closer toward alert fatigue rather than toward dev.

It’s time to talk about the elephant in the room

A long overdue chat…

Security is like the spotty-little ginger kid who never gets the invite to the party: on their own, ostracized by all, and with background finger-pointing sniggers and whispers galore. But here’s the irony…

…the security bottleneck isn’t security’s doing.

Indeed, blaming security for the security bottleneck is akin to dumping your trash over your neighbor’s fence and then complaining to all and sundry about the stench, unsightly pile, and vermin that’s always there.

Stop dumping your trash in my backyard!

Security doesn’t cause the security bottleneck.

If I put a new wheel on a car but only use 2 of the six retaining nuts and then send it to you to safety stamp it as ‘good to go’, you’re likely to send it back to me. You might do it to keep the line moving if you have four nuts to hand.

But what if that happened repeatedly?

The security bottleneck’s the same. Developers introduce 98% of bugs and vulnerabilities in code, and it’s they who create the jam (and, unintentionally, of course, always have done).

Remove the 98% and eliminate the problem.

If you remove 98% of known vulnerabilities and bugs at source, you eliminate the bottleneck. Unfortunately, the problem with removing them is that developers and security training have never mixed. (One cunning linguist termed security as being soul-withering).

Regardless, the situation is unsustainable and lacks a viable technological solution–GuardRails has the answer to eliminating this 98%, by the way–any change drivers must first come from the organization, followed by people, processes, and culture–DevSecOps.

DevSecOps

DevSecOps integrates security into DevOps processes but is primarily about culture, people, and processes. Tools and tech are essential to DevSecOps practices, but only in how their automation capability will advance culture, etc., and aid in dismantling the barriers between, first, the teams themselves and, second, between teams and tech.

“DevSecOps teams simply don’t exist.” [2, p 45]

Another key aspect of the DevSecOps culture is that security must be everyone’s responsibility. (And accountable, as it relates to their roles, of course.) Whatever your current organizational state, embracing DevSecOps means instigating a security-oriented culture. Such a transition will naturally take time, but there are measures you can take to secure your change (Also, feel free to check out our white paper on How to Build a DevSecOps pipeline, it may help. Link is at the bottom of this page).

Because automated security testing is at the heart of DevSecOps, security automation will need to become an integral component of application security (AppSec). At GuardRails, we call this True Left. Similar to Shift-left, the fundamental difference between the two is that rather than shifting security testing left, we start from the left.

True Left = integrated AppSec. Full security automation from code to cloud throughout all your development lifecycle and pipelines. True Left goes hand in hand with DevSecOps and is the next iteration of the software development lifecycle and the next era of cybersecurity.

The Future of DevSecOps (and the DevSecOps movement)

DevSecOps is the critical next stage for organizations. The old way of developing apps is outdated, and organizations should take a holistic approach to how they not only implement security but think about it. DevSecOps incorporates this (and is essential), but implementing DevSecOps does take time.

However, glancing at the daily headlines is proof enough of both need and urgency. Adding weight to that argument is the fact that 60% of small businesses go under following a single data breach, and you don’t want to be just another failure statistic.

DevSecOps has to be the answer.

Head of IT Security & Compliance at AirAsia Group)

What next?

If your organization wants to implement DevSecOps, there is much to do. As our white paper below shows, you must take time and do it right. Do you concentrate on developing the culture, people, and processes while praying hackers don’t notice the holes in your AppSec and leave you alone while transitioning? 

Or would you prefer end-to-end and code-to-cloud AppSec across all your pipelines to give you peace of mind while you do so? With your software development life cycle and environments 100% secure, you can then take the time to plan, test, and transition your culture, people, and processes to your desired DevSecOps end-state. (GuardRails also helps you to eliminate that 98% of bugs and vulnerabilities too.)  

Of course, there is no right or wrong answer, but doing nothing isn’t an option. Regardless, what price is peace of mind?

How to Build a DevSecOps Pipeline white paper

Click here to get our How to build a DevSecOps pipeline white paper.

Bibliography

Wilson, G. (2020). DevSecOps: A leader’s guide to producing secure software without compromising flow, feedback and continuous improvement . Rethink Press.

Allspaw, J., & Hammond, P. (2009). Velocity 09: John Allspaw and Paul Hammond, “10+ Deploys Per Day”. (https://www.youtube.com/watch?v=LdOe18KhtT4). O’Reilly.