I'm not a fan of the "DevSecOps" or "SecDevOps" terms. Security is just part of DevOps, the same way QA or product management are. It's not its own thing bolted on top of DevOps practices, it's an integral part of the product.
That said, I agree with the blog post. We are seeing more and more security teams reinvent themselves as they adopt DevOps practices, which really means security is learning to use the CI/CD pipeline and to build controls in IaaS and PaaS. We're moving away from security teams that panicked at the idea of not controlling layer 2 and 3, like they used to in the goold old datacenter, and seeing teams focus on web application security more and more.
It doesn't mean L2/3 are not important. There is still a lot of value to adding an IDS or a proxy to an infrastructure. But there is also tremendous value in testing controls continuously in the delivery pipeline, which means collaborating with devs and ops in the CI/CD pipeline. That's really what "secdevops" is about.
In the next few years, we'll see more and more security teams learn DevOps and that's a good thing. Let's just make sure we don't reinvent decades of infrastructure security in the process.
Many years in IT, little and big companies... I've seen 3 security models:
1) Absent. Everybody was so worried about other keywords, than nobody did remember about data security until it was a problem.
2) Invalid, unmaintained and written in the past by a third party. Everybody call this model components "the protocols", nobody knows about security, they know about "follow the protocol", or "this does not follow the protocol".
3) Conscious about threats, maintained and perfectly explained by the involved people.
The 3 models, did repeat before, and during the term "devops". And will repeat after. And will be immune to the existence/usage of the term "secops" in the media.
For the model 3), I've found 2 scenarios, 3a) management was conscious about security (even more than "technical people") or 3b) management didn't know almost anything about the sysadmin work, but they did know they didn't have problems.
One of the keys for the model 3) is management. They push the workers in one direction or another. If management does not understand the value or the dangers of data security, usually they have problems in more fields than security (technical debt, code, tooling, teams, projects, etc)
When people expects my response to an automation or integration or development question (devops), and I give them the response, with all the security aspects included, (not just a "technically valid" response) I use to gain value with the customer/team.
Now I think I was a secops (before the term was out there), when my boss just did want a 'devops' at the time.
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.
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.
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.
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.
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.
I mean to imply more that every time we have a new paradigm shift in titles, job responsibilities get increased. For example, it's not enough to be a backend developer, now you must be a full stack developer, so that we can hire fewer front-end devs. It's not enough to be a DevOps engineer, now you must be a FullStackDevOpsEngineer. There's this concept that out there is some superman engineer who can somehow be an expert in everything.
Security is hard. Conforming to security best practices is one thing. Being a security expert is in itself an entire career field.
I was going to say something similar. So it's a three way marriage, dev + ops + opsec?
Most companies I know can't even find one person who can do dev + ops well. I've only met a few people. Usually there are ops people who can do a little dev and dev people who can do a little ops. I've seen a few companies where it is a productive marriage but most companies I know just throw Docker into the dev environment and call it devops.
Now imagine having all three be the same role?
> DevSecOps is propelling forward-thinking organizations by doing something simple — fostering collaboration of seemingly contradictory teams to align their disparate goals into a singular effort.
This is not how devops works! Dev ops merges the two teams so that everyone is responsible for both. It doesn't just have the two teams "work together"... the two teams have been "working together" since the web was invented. Devops, by most definitions I know, is where developers are responsible for thinking about and dealing with the operations issues rather than having another team.
As a side question, is it opsec or secops? I've always heard the former.
(edit: reply is on the first part, but i might need coffee :) )
I'm not sure the goal is to have someone who is some kind of horizontal fullstack guru in all spheres, from management to hardcore security.
Rather, people with those skills should work together, instead of staying in their silos, by automating the friction points between them all and making the process more "parallel"?
100% agree with this. The point is to have one team working together, where the team has all the required dev, ops, and security skills, or access to tools that can augment the team's skills.
Each member of the team does not need to be a superhero, they just need to be jointly responsible.
The question is how your partition your organisation. Classic is something like Development | Testing | Production. DevOps wants to integrate the different department, but you cannot build one huge team of 100 people.
You could partition by product instead Gmail | Search | Maps | etc.
You could do both partitions, which gives you Matrix Management [0]. In the software world this is more commonly known as introducing the role of a product manager in addition to a team manager.
Just to clarify, that's how I run it here but I've been told by some fairly respected devops people that it's not really devops. But in general I agree.
Well, part of the idea as I've heard it from "devops experts" is to make ops so automatic and engrained that it becomes a natural part of development.
Obviously a front-end developer wouldn't be worrying about server configuration, but they can write the integration tests and deploy when they are done without involving another team assuming the test coverage is sufficient / code review is done / etc.
it's my belief based on experience that all 3 - dev, ops, and security are pretty much a giant slow motion trainwreck everywhere except maybe the big 4. and maybe not even all 4.
this industry is doomed from a job function perspective. we keep making our own jobs more complicated and blurring the lines instead of gravitating toward more rigor. the accountants are doing it for us, and they do a shitty job because it's not their actual industry.
i'm in my last pure tech position. it's becoming too much to deal with relative to the money paid, because the expectations of a 24/7 internet are outpacing our ability to deliver with reasonable compensation and quality of life. i don't see it changing. i only see it getting worse, year by year.
You gotta get out of wherever you're at. There are tons of 9-4 dev jobs in the F500 where it's easy to stand above your peers without working too hard. The benefits can be nice too.
you mean the companies that are constantly getting breached? working for a fortune-class company is just a different flavor of the same underlying bullshit, and one that i especially dislike.
also "just don't work that hard, and collect checks" is not really how i operate. good for you though.
sorry, I read the article and the word BuzzOps popped in my mind. I think most companies are still trying to get their heads around clouds and micro services.
Amen. I'm so tired of self proclaimed "Thought Leaders" coming up with bombastic new buzzwords to sell to managers. In my eyes, the DevOps "movement" has mostly been a complete failure. It went from being about cultural change to half of the people thinking it's about Operations writing automation and the other half thinking it means no Ops team at all, and developers doing everything.
Ever heard of a jack of all trades? It's true that jacks are super valuable but a jack is not an ace. Following this model feels like your spreading your brain power in to too many disciplines.
There's also obvious moral hazard with this model. It's kinda like the fox guarding the hen house. Having the same department be code writer, operations and auditor seems like an awful Idea. If one has a tight dead line, they're going to cut corners. We've all seen it.
This model can only exist in a start-up because of man power constraints. Your first few hires are going to be amazing and may actually be capable of such a role. However, as time goes on, this person has built a castle that can't be touched. You're also going to find that as a company grows, the spread of aptitude and skill grows wider, making this model seem absolutely absurd. The simple chaotic environment that your """"secdevops"""" started in will not be the same two years from now. Newer employees are going to lack contextual knowledge due to the increased complexity and by the simple fact that they didn't build it.
In practice, most people are partly responsible for keeping the organization secure. This isn't news...
I think that calling this a marriage between DevOps and SecOps is a serious misnomer.
Traditionally, SecOps people are very IT oriented, and spend their time auditing existing infrastructure for vulnerabilities using automated tools, watching for hostile network traffic, etc. Very little programming or application security knowledge is required, but lots of networking and IT knowledge is required.
I assume that by SecOps, the OP is referring to Application Security Engineering. This field works much closer to the developers, has knowledge of how to build security into products, and usually has programming experience.
This might seem like a nitpick, but the difference between SecOps people and AppSec people is big enough that if you were to hire the one for the other's job, you'd have a very bad time.
I'm not sure what a more accurate name would be (AppSecOps? AppSecDevOps?), however calling it DevSecOps is too misleading.
This seems like a pretty good development overall - more people looking at application security across the org is a good thing imo especially if it can provide another layer of defence for where the app developers missed something or around new vulnerabilities just discovered. Even for things like Wordpress, I like the additional hardening of a WAF and with tools like OSSEC (and eventually more advanced tools like Immunio) on top of the usual app hardening.
That said, I agree with the blog post. We are seeing more and more security teams reinvent themselves as they adopt DevOps practices, which really means security is learning to use the CI/CD pipeline and to build controls in IaaS and PaaS. We're moving away from security teams that panicked at the idea of not controlling layer 2 and 3, like they used to in the goold old datacenter, and seeing teams focus on web application security more and more.
It doesn't mean L2/3 are not important. There is still a lot of value to adding an IDS or a proxy to an infrastructure. But there is also tremendous value in testing controls continuously in the delivery pipeline, which means collaborating with devs and ops in the CI/CD pipeline. That's really what "secdevops" is about.
In the next few years, we'll see more and more security teams learn DevOps and that's a good thing. Let's just make sure we don't reinvent decades of infrastructure security in the process.
(shameless plug: I'm writing a book on devops security: https://securing-devops.com/book)