[secretmike]

I've heard DevSecOps, SecDevOps, and DevOpsSec :)

This is really all caused by the rise of the Service as a unit of delivery. Web applications talk back to Services, which provide access to vast amounts of information. Same with mobile apps and APIs.

At one time the "security team" really meant the Network Security team. The people who controlled the firewalls. As web applications became more complex, the model was extended to Web Application Firewalls, that had a bit of knowledge of what web requests looked like, and what bad payloads looked like. But still trying to protect the application from the perimeter.

These days services are much more powerful, and connect to much more data. Form POSTs are now also Ajax calls, or JSON over websocket. They are also deployed in more ways: AWS, Heroku, Docker, Mesos/Marathon, Kubernetes, etc. Trying to completely control the network becomes more complex.

To effectively protect applications today, the security must be embedded within the application, where the defences have a full understanding of what's going on, and where the security always gets deployed as part of the app, no matter where it runs.

Similarly, it makes complete sense to me that the "Security Team" also needs to be embedded within the development team.

One team, responsible for the design, implementation, operation, and retirement of a system.

[lmickh]

Sadly, this is what "DevOps" was supposed to be about when the discussions started back in 2010ish. Getting all of the people required across the entire business working together so that road blocks could be removed as close to the problem source as possible.

The fact that we even see DevOps teams tells you how horribly the point was missed. Instead of changing the way they do business, folks seem content to sprinkle in some automation and call it a day. I work in a company that put together a DevOps team despite trying to explain that to them. Now we have the same problems as before. They are just somewhat automated now.

[qznc]

I have given up on defining buzzwords like DevOps, Cloud, Mobile, Agile, Industry 4.0, Code of Conduct, etc.

If you want to change something in your organisation/project, just pick a few buzzwords. It gives your proposal a halo of modernism and progress. If you get rejected, try different buzzwords. You want to integrate developers and admins better? You can do that under the DevOps umbrella or the Agile umbrella or whatever.

Using a new buzzword gives people hope for change. Without hope they will not be on board. If they are not on board, change will fail. It works like a self-fulfilling prophecy. Only if people believe it, change can actually happen. If the actual changes fail, the buzzword is burned. Find a new one for another try.

This model explains very well why the buzzwords change quickly. The words don't matter. The definitions don't matter much. People will use and misuse them not matter what. You can misuse a buzzword to create change for good.

[philsnow]

I hear the same thing said about having a "mobile team" or an "ios team" + "android team" (that people commonly think sprinkling a little "mobile" on the codebase makes everything fine, but no, mobile should be everybody's responsibility and you shouldn't have a mobile team).

What's the limit ? Should all specialized skills be uniformly distributed across the whole engineering org ? How is that conducive to the idea of "teams" at all ?

I think this organizational strategy works better with smaller orgs.

[jvehent]

I couldn't agree more. At Mozilla, the Services Security team is part of the team that develops and builds services. We work with devs and ops every day. We write application and infrastructure code. We share successes and failures.

The traditional bystander/compliance security team approach shows its limits very quickly. Being embedded that deeply into the DevOps team is by far the most efficient way to secure services.