DevOps and DevSecOps: A tale of 2 Ops
- Author: Neil Dundon
- Date: 31 Oct 2018
“DevOps”, and “DevSecOps” and all these words being thrown around may sound like tech industry buzzwords despite being around since 2015 but increasingly they are becoming a part of the software development fabric with large firms and companies placing an increasing emphasis on DevOps and DevSecOps practices. But what’s the difference between all these terms?
Once upon a time, before the implementation of DevOps, in the magical realm of Software Development Land, development and operations teams were separate and independent with their own agenda.
They had differing views, differing agendas, differing goals. Developers wanted to push out software faster and faster causing a wave of aneurysms in the Operation camp. Operations at the time wanted no part in these faster and faster deployment times, knowing that quick changes without the appropriate safety protocols could undermine the system.
Thus DevOps was born, a new way of doing things to reconcile the 2 wildly different schools of thoughts.
Guided by a common set of principles, Operations and Developers would strive to:
1. Set expectations and priorities and define the fundamental beliefs that guide them.
2. Disregard silos and encourage collaboration between all teams for issue addressing.
3. Automate mundane and repetitive processes to save resources for more intense higher-level work.
4. Incorporate feedback into all stages of work, constantly calibrating everything that is moved into production.
5. Proliferating the data to everyone involved to generate a greater culture of collaboration.
Because of Devops, the software development dilemma was solved; system administrators, developers, users, engineers would be combined and coordinated into a singular, automated workflow with a mutual goal: “The lightning fast deployment and delivery of high-quality software that addresses all user needs while retaining the stability and integrity of the whole system.
Then someone said “what about security?”
...And in that moment, DevSecOps was born.
In a software development context, the school of thought around security holds the view that once a system has been designed, security defects are then detected and corrected by operators before the system is released.
In theory and in a hypothetical perfect reality where taxes don’t exist, this allows a limited finite supply of precious skill in security to be applied to outcomes and avoids the need to escalate the security context within the overall whole system.
Unfortunately we are not in this blissful hypothetical perfect reality and regrettably taxes do exist, so this traditional process of firstly designing the system and rectifying issues afterwards has its limitations. Increased business demand for DevOps, Agile, and Public Cloud services means that tradition security management processes have become an obstacle.
It is very rare that the security team possesses enough information to implement a security decision that will still seem logical at the end of the value creation life cycle. This factor combined with the emergence of DevOps meant that traditional security is no longer an option.
Instead of allocating risk reduction to security specialists and leaving the responsibility on their shoulders, why not push for risk reduction and security to be embraced and improved upon by all members of the organisation while aided by those with the capabilities to contribute security value into the system.
Built from the mindset that “everyone is responsible for security and I mean literally everyone”, DevSecOps has the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing safety required.
The mindset implemented by DevSecOps creates collaborative mechanism where business operators are equipped with the relevant tools and information to make security decisions in conjunction with security staff support. DevSecOps engineers are able to contribute continuous value by constantly conducting surveillance and attacking as well as determining defects before actual non-cooperative intrusions can happen.
Make no mistake however, this proactiveness and decentralized vigilance as a result of shifting to DevSecOps requires senior management to be informed and involved with key information of how the company is operating and defending itself against an increasingly complex and increasingly inconsistent business environment.
It is no small change adopting SecDevOps, it is a change that requires commitment and confidence from all verticalities of the business but it is a change that your organisation will not regret if it is done correctly.
If all this talk of Devs, Ops, and Sec has made all you DevSecOps and DevOps experts in the audience hungry for some opportunities to sink your teeth into, we here at CryptoRecruit have some outstanding opportunities open. Email email@example.com to get in touch.