What's in a Name: Does DevOps Need a Security Flavor?

Tuesday, June 12, 2012

Rafal Los


I've been reading and discussing DevOps a lot lately.  

Lots of intelligent folks out there are trying to remove the bottlenecks between what we traditionally know as development and the deployment (operations) functions within an organization to get IT to a more agile state.  

Every once in a while someone talks about security - and lately I've been trying to figure out whether, and how, we should be discussing the DevOps and security relationship.

While for the last decade or so security teams have been trying to make their way into the software development lifecycle (SDLC) I think it's interesting that the struggle doesn't seem to alleviate itself any in the 'new' world order of DevOps.

Security seems to continue to struggle for identity and the security function seems to want to stand apart.

I've seen "SecDevOps" discussed, "Rugged DevOps" and and on and on with different names, acronyms and references being made... and it's all left me wondering if we're making the same mistake all over again.  

Why does security need to be explicitly called out in the DevOps methodology?  Why does the application of sound risk-mitigation strategies within the software development lifecycle (no matter how it shapes up) need its own name and specific call-out?

I don't believe it does.  Incorporating security into DevOps should just leave us with "DevOps" not some Frankenstein's Monster variation of another strange naming convention.  "SecDevOps", "Rugged DevOps" or whatever - I think it's a mistake.  

Here's where my head's at ...

The only reason to explicitly call out whether we're adding security function into a movement like DevOps is if there are use-cases where security is absent.  I can't think of one such case, so why would we want to have a "SecDevOps" vs. "DevOps"... where one implies the absence of security principles?

Maybe I'm over-thinking it, but explicitly calling out the application of security to DevOps is a bad idea in my mind.  It perpetuates the notion that security principles are something that is apart from the development and deployment cycles and that security is something that is an add-on.  Haven't we struggled with that for over a decade now?  

Why would we want to continue this? Curious what you think...

Cross-posted from Following the White Rabbit

Possibly Related Articles:
Application Security Security Strategies SDLC Secure Coding Network Security Software Security Assurance Information Security DevOps
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.