Is Security a Dev Problem or an Ops Problem?

I’ve been working on an ebook for The New Stack about DevSecOps. There are aspects of DevSecOps that are essentially positioning problems: How is security positioned in the organization? How the organization handles security depends on the context that it creates around security and the story that executives, engineering leaders and individual engineers tell themselves about how security fits into the software lifecycle.

I first started thinking about this because on The New Stack’s website, articles are organized into three categories — architecture, development and operations. The sub-category for security is under the development tab, which strikes me as odd — I probably would have put it under the ops tab. But there are good arguments for making security a ‘part’ of development. In fact, that’s the core of the DevSecOps movement. But because security has traditionally been more aligned with ops than dev, it seemed odd to me. Also, DevOps as a subsection is under the ops tab.

Now let’s put our product positioning hat on. Let’s say you produce a security tool that makes it easier for developers to take control of security. As you’re thinking about how to segment your market and how to communicate your point of view about security, you should very explicity articulate that your product is for teams that hold developers responsible for security. This will exclude a lot of organizations — in this survey from Logz.io only about 30% of developers said their team had responsibility for security.

But excluding the majority of organizations is pretty much the point of effective positioning.