DevSecOps: Not Just a Clunky Contraction, but a Requirement

DevSecOps: Not Just a Clunky Contraction, but a Requirement

DevOps is and was a contraction of two ways of doing IT: The Development way and the Operational way. Two teams that just did things differently. They had different priorities, different incentives, and often different reporting structures. Their contraction had to happen for The Cloud to be fully embraced. That was the plan at least…but DevOps, unfortunately, stayed an IT “goal” or “KPI” for too many quarters at some places and has recently lost favor to a newer wave of IT spending and terminology allegiance.

I think this is a mistake. DevOps is real – and your company will not succeed in your market without its’ adoption.

Now, get ready for the newest addition to the already controversial contraction – DevSecOps is here – and it is going to fix some of the problems that DevOps introduced.

Some Background:

In the early cloud era (2008-2015) I left software development to begin working full-time in a series of consulting firms responsible for some of the best public, private, and hybrid Clouds of that period. During that time, I had personal experience with some of the early leaders in the DevOps space and I worked with several Fortune 50 companies implementing this newer, more “agile” method of service delivery that collapsed the silos of Dev and Ops into one workable team.

(A great illustration of the pain of those years is the book: “the Phoenix Project”. I still recommend it to anyone I find that hasn’t already read it – and to some that need to read it again.)

Back to the Story:

Where DevOps worked it worked GREAT! Projects were on time and successful. Collaboration between disciplines was real and game changing. The “Six Million Dollar Man” goals of “better, faster, stronger” were actually coming to fruition. The sea had been boiled, the paradigm had been shifted… Houston, we had synergy!

However, there have been failures. Big ones and the biggest of the big always managed to make front page news. Code and design flaws exposed by this new model led to some huge intrusions. Applications and “data lakes” that were pushed for “speed to market” without a thought for privacy, auditability, or data integrity were being exposed, almost monthly, by an army of patient and persistent script kiddies.

So, If DevOps is this great, and it is, why are we not always better than we were before we embraced this “better, faster, stronger” way of accomplishing work?

The answer is in the question. DevOps is “better”, DevOps is “faster”, but is DevOps “stronger”?

DevOps is “better”

It wasn’t too long ago, so I’m going to assume that we all remember the not too distant past of buggy, super specific and ultra-expensive software and hardware. The non-compatible video or music player that cost one week’s wages. The million-dollar enterprise application that was only for basic storage management and only for one vendor. The billion-dollar website that was only for email. We have gotten markedly better – it is undeniable.

DevOps is “faster”

This is measurable in everything from the phone you now carry with you everywhere to the financial apps that we use daily to do things that we would NEVER have considered doing digitally just two or three years ago. The speed at which we are changing the world with this new design and delivery methodology might best be described as: ludicrous.

DevOps isn’t “stronger”

Even with all the progress of DevOps and the new integrated approach to projects, the role of security, audit, and verification was often isolated to a specific team in the final stage of development. That wasn’t a big deal when projects lasted months or even years, but the “better”, “faster” DevOps has enabled much more compressed timelines (sometimes weeks or days), but security practices added as an afterthought have tripped up more than one outcome.

Insert variable “Sec”

Adding Sec into DevSecOps means that security is in the middle of the project, in the middle of the work, and in the middle of the deliverable – not the end. This is the missing piece to the agile puzzle. We now know that combining teams and tools works – so for a “stronger” deliverable we need to add another team and more of their tools. As with the earlier contraction of Dev and Ops teams, automation and thoughtfulness in the Audit, Secure, Verify space will be the timesaver when Sec is added effectively into the agile teams.

We will be putting out more blogs and even a whitepaper or two about this topic over the next two quarters, so let us know what you think and if you would like to talk more about this topic. Or, if you would be interested in getting an expert perspective on your Audit, Secure, Verify stance throughout your application stack … drop us a line.

Contact Us

Share to: