What is DevSecOps, as opposed to DevOps?

1.2k views2 Upvotes4 Comments

Senior Director of Software, Applications and Analytics in Software, 5,001 - 10,000 employees
DevSecOps is people, processes and tools. No matter what, if you’re being an advocate for change in organizations and leading a number of agile transformations, those things have to work together to drive the security posture. You can have security, but it only gets you so far without DevSecOps. The foundational component really is culture. DevSecOps gets misconstrued as just being tools, and building a pipeline, but it's so much more than that. It's that broad encompassing cultural piece that really unites it in all fronts. Everybody's responsible for the security posture, no matter what your role is. You have to have the posture for the continuous cycles that go through DevOps and you have to have a culture that supports it. The culture can’t work in silos: everybody shares responsibility because there's a common mission. We all, no matter what we do, no matter what our specialty is, have a responsibility in marching towards that mission. Whether you call it DevOps or DevSecOps, I prefer DevOps, because I feel like security needs to be inherent in it.
3 1 Reply
President and National Managing Principal in Software, 501 - 1,000 employees

I definitely agree that, yes, security should be baked into DevOps, but if you have to put sec to the word to remind people, and to make that a cultural aspect. I think that's good as well.

President and National Managing Principal in Software, 501 - 1,000 employees
There is a cultural component to DevSecOps, it's not just an enacting a tool, or even a process. You have to live and breathe the vernacular. But from my perspective, it's the difference in going into a company that only does the basic things (change control, some limited amount of security testing, their annual penetration tests, etc.), and another company that has testing baked into their SDLC, that's really aggressively testing for security as part of QA (they may have a bug bounty program, internal, external, etc.) As an assessor, my job is to write a report and to basically tell the story of what the company's doing from a control perspective, so their customers can gain comfort. Coming into a company, that's got that higher level of sophistication—people beating internally on their applications, 24/7, and always looking to break things on purpose—that to me is DevSecOps in operation.
Staff Security Engineer in Software, 11 - 50 employees
I'm the security officer at a very small startup. We're actually wrestling with this question right now. The idea that security has to be a fundamental part of your process really resonates with me. That is definitely the thing that differentiates DevSecOps from DevOps. It is about making sure that all of my developers, everybody in engineering, has bought into not only being able to do things through tooling and automation but also into making sure that we're doing things in a secure way. When DevOps started, everybody said, "Okay, now the developers can own the operation side of things as well, and they can contribute there." But they also need to own the security aspects of the application. I can't be “the security person” responsible for all the security related functions. The team that's building the application and using those security tools that I've suggested to them, has to have an awareness of security as well. Of course I need to understand their processes and motivations as well - it goes both ways.

Content you might like

CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.
Read More Comments
40.7k views131 Upvotes319 Comments

Patch management: to reduce attack surface and avoid system misconfigurations39%

Malware and ransomware prevention: to protect endpoints from social engineering attacks59%

Malware and fileless malware detection and response: to protect against malicious software49%

Threat Hunting: to detect unknown threats that are acting or dormant in your environment and have bypassed the security controls33%

Not planning to change endpoint security strategy9%



Limited environment/Infrastructure resources32%

Inability to quickly identify the root cause of CI/CD pipeline failures45%

Lack of standardized CI/CD pipeline templates across the organization54%

Integrating security tools - inefficient security implementation leading to false positives38%

Poor communication across business and product teams/coordination challenges26%

Cost/resource management26%

Implementation of CI/CD into on-going projects and workflows22%

Internal resistance: training issues, culture, etc.14%

Inefficient implementation of CI/CD due to lack of expertise, poor training, etc.19%

Poorly written unit and acceptance testing9%