Click-bait aside…I am tired of seeing articles and presentations about DevSecOps only to find out that it is just standalone security procedures shoehorned into a vague development and/or operations process.
DevSecOps is more than just “Sec” smushed in-between “Dev” and “Ops.” Today’s DevSecOps message has expanded beyond the original concerns of shifting security “left” into a message of shifting it everywhere. And if you are really observant, it’s about shifting more than just security. It’s about any process that has been left out in the cold, such as: finance, compliance, and legal. Everything, everywhere, all at once.
The term “DevSecOps” gained popularity approximately 10 years ago because security concerns were largely neglected in the DevOps processes of the day. I still argue that security is an operational concern and should have been emphasized under the Ops umbrella of DevOps. But – regardless – the fact of the matter was that security was often a separate concern that came in after the programs were written.
This meant that the security process had the potential to derail everything. To keep that from happening, security needed to be addressed and added to the mix earlier in the process. And thus, Sec was added to reinforce this need for everyone.
No developer, security professional, or operational team can be expected to continuously monitor, test, deploy, review, hack, and heal without copious amounts of automation in place.
But you can’t just talk about security, alone, and call it DevSecOps. At least not in my world.
Dev-EVERYTHING-OPS?
DevSecOps subsumes all of the elements of DevOps and shouldn’t stand apart. That’s why it’s in the middle of the term. And, yes, I’m aware that at one point they were trying to call it SecDevOps. Please stop trying to interject logic into my rant.
In either abbreviation, security is included in the process – integrated throughout and not as an afterthought. To enforce that concept, you shouldn’t talk just about security as DevSecOps without including how to integrate it into the entire developmental and operational gestalt.
However, over the past 10 years, the number of processes and issues that need to be “shifted left” has expanded. Just like security concerns, budgetary and financial issues can come in at the end of the process and disrupt a good production launch. This has given rise to FinOps. Security’s twin sister, Compliance, can do the same which has resulted in new compliance management automation with CBOMs and compliance-as-code.
Anything that could upset the process at the end needs to be addressed throughout. And we can’t keep adding to the abbreviation. So, DevSecOps arguably has to include it all – FinOps, testing, legal reviews – Everything.
Shift security left, right, and everywhere!
When it comes to the “Sec” in DevSecOps, the message has also expanded from shifting security to the left – in the developers’ laps – to shifting it everywhere.
Yes, your developers should be trained on writing secure code from the start. And there should be tools to review the code and provide quick training on specific security issues that have been identified in development. But security should be reviewed throughout your CI/CD pipelines and addressed in production environments with chaos monkeys and continuous red team ethical attackers.
…over the past 10 years, the number of processes and issues that need to be “shifted left” has expanded. Just like security concerns, budgetary and financial issues can come in at the end of the process and disrupt a good production launch.
Ahhh…a self-healing, anti-fragile production environment…a man can dream!
And of course, automation plays a vital role. No developer, security professional, or operational team can be expected to continuously monitor, test, deploy, review, hack, and heal without copious amounts of automation in place.
Treating everything (configurations, infrastructure, compliance, and – yes – the code) “as code” can get you there. This means that all information should be source-controlled and monitored, keeping track of who changed what and when. And then all manual processes are automated from the information tracked in your source control. Make these automation tools available to developers before they check in any code change and you will have shifted all of your concerns – Everywhere.
For me, this has morphed into the notion of continuous software engineering, or ContinuousX, where X is everything in the software development lifecycle (SDLC): integration (CI), delivery (CD), deployment (also CD), improvement, security, testing, monitoring, feedback – you name it – All at Once.
So, yes, security is A PART OF DevSecOps. But, as such, it should not be APART FROM DevOps. Addressing all of your software lifecycle needs continuously with automation is the name of the game in today’s DevSecOps approach. Something to keep in mind when someone else is telling you that their security application is “DevSecOps.”
