Just about any DevOps shop will hit speed bumps on the path toward continuous learning and improvement. When it comes to DevSecOps, however, the biggest obstacles are rarely technical — they are cultural.
“Organizations are increasingly adopting DevOps environments in hopes of achieving transformative velocity and innovation. But like any new business initiative, this comes with challenges — and in the case of DevOps, it’s often around culture and areas of responsibility.”
Elizabeth Lawler, VP of DevOps Security, CyberArk
Even problems that look technical on the surface are usually rooted in people. Security is a prime example: it is as much a matter of culture and ownership as it is a technology problem. And even high-functioning DevOps teams struggle to make security — and security teams — genuinely integral to the development process.
This friction is both a driving force behind the DevSecOps movement and, paradoxically, a source of resistance to it. Below, we identify the three most common cultural roadblocks and then share five concrete strategies from practitioners for overcoming them.
The 3 Cultural Challenges Blocking DevSecOps Adoption
Challenge 1: Security Is Still Treated as Something That Happens “Later”
“The biggest change in mindset necessary to create a mature DevSecOps practice is to understand that security cannot be done as an afterthought. Rather, it requires the attitude that it is built into the continuous delivery pipeline.”
Premand Chandrasekaran, VP of Software Engineering, Barclaycard
The traditional model treated security as a post-mortem: infrastructure was built first, then a security audit was bolted on at the end. That model breaks down completely in modern cloud-native environments, where entire infrastructure stacks can be spun up and torn down in hours.
“Today, DevSecOps professionals are tasked with baking security into architecture as they build, and into the system as it’s deployed.”
Tim Jefferson, VP of Public Cloud, Barracuda Networks
When environments are ephemeral, a security review scheduled for “after deployment” may never happen at all. Shifting security left — earlier in the pipeline — is not optional; it is a structural necessity.
Challenge 2: An Us-Versus-Them Mindset Between Dev and Security Teams
The tension between developers and security practitioners is not new. The root cause, according to Meera Rao, Senior Principal Consultant at Synopsys Software Integrity Group, is that each team operates with its own roadmap, its own priorities, and — critically — completely different incentives.
“Security teams have long thought that developers were not interested in security. Along those same lines, security teams also thought developers believed that security wasn’t their responsibility.”
Franklin Mosely, Senior Application Security Engineer, PagerDuty
Neither assumption is necessarily true. But the divide persists even in relatively mature DevOps shops. As long as security remains a separate entity — organizationally siloed from development and operations — the us-versus-them dynamic is structurally reinforced, regardless of individual goodwill.
Challenge 3: The Belief That Security Hinders Innovation and Velocity
“We are all very used to this romantic image of the resourceful developer who codes swiftly and slickly — but not necessarily securely, because security has been viewed as the antithesis of function. Thus, a big cultural challenge for DevSecOps is to instill order in the face of a legacy of chaos, and somehow accomplish this without hindering innovation.”
Robert Hawk, Privacy and Security Lead, xMatters
Years of bolt-on, last-minute security reviews have created a deep-seated perception that security teams exist to slow things down. As pressure for faster, more frequent releases intensifies, this perception hardens into outright resistance. The irony is that this cultural challenge is precisely what DevSecOps is designed to solve — yet it is also one of the primary reasons organizations resist adopting it.
“Speed, velocity, and resiliency do not need to be sacrificed in order to be secure and have more stakeholders at the table.”
Elizabeth Lawler, CyberArk
Note that all three challenges are interconnected. Treating security as an afterthought breeds siloed teams, and siloed teams reinforce the belief that security blocks progress. They tend to compound each other.
5 Strategies for Building a DevSecOps Culture
Overcoming these cultural obstacles requires movement on two fronts simultaneously: organizational alignment and technical strategy. The following five approaches are drawn directly from practitioners who have implemented them.
1. Have People Walk in Each Other’s Shoes
Ignorance breeds resentment. When developers do not understand what security teams deal with, and security teams do not understand how software actually gets built, mistrust fills the gap. Many DevOps teams already create cross-functional empathy by rotating developers through on-call duties alongside operations staff. The same principle applies to security.
“The security professional needs to walk in the developer’s shoes and learn how software is made and the issues that are faced. It’s best to work with developers to come up with solutions that allow them to do the right thing when it comes to security.”
Franklin Mosely, PagerDuty
The reverse is equally important. Developers need to engage with security colleagues to understand best practices for securing modern infrastructure and applications. As Lawler notes, security must be built into development processes early — and that can only happen when both teams actively collaborate rather than lobbing requirements over the wall at each other.
2. Provide Real Learning and Training Opportunities
Many DevSecOps cultural problems stem from a straightforward lack of knowledge. A developer who has never been held accountable for the security of their code has had little incentive to learn secure coding practices. A siloed security team may have little idea how the software they audit actually gets built.
“Most developers aren’t trained in secure coding best practices. This creates a situation where engineers are not implementing security thinking and awareness into design, coding, and testing.”
Franklin Mosely, PagerDuty
Training takes many forms. Formal secure coding curricula, regularly scheduled security audits, and unannounced audits all create learning moments. Chandrasekaran of Barclaycard also recommends adversarial exercises such as “hack days” or capture-the-flag (CTF) events, where cross-functional teams actively find and exploit vulnerabilities in a controlled setting. These exercises build empathy and practical knowledge simultaneously.
3. Embed Security Professionals on Development Teams
The fastest way to break down a silo is to physically remove it. Embedding a security engineer directly on a development or DevOps team gives security a literal seat at the table from day one of a sprint, rather than a seat at a review meeting after the code ships.
“IT leaders should create avenues for security experts to be involved in designing, developing, and testing code. One way is to embed security team members directly into development teams.”
Kiran Chitturi, CTO Architect, Sungard Availability Services
PagerDuty has used this approach in practice. According to Mosely, embedding a security engineer on a product team allowed that engineer to learn the team’s tools and processes, while the development team gained direct exposure to security best practices. The result: the security team became better at adding value without blocking delivery, and the product team became more conscious of protecting customer data.
4. Launch a Security Champion Program
Not every team can spare a dedicated security engineer. A security champion program is a practical alternative. A security champion is typically a developer or DevOps practitioner — not necessarily a trained security specialist — who volunteers to develop deeper security knowledge and acts as a liaison between their team and the security organization.
“Establishing a training and security champions program allows members of development teams to learn and volunteer to build software security skills and awareness through mentoring, training, and working closely with the application security teams. These security champions form the front line when it comes to guiding development teams on application security and bridge the gap that exists between DevOps and security teams.”
Meera Rao, Synopsys Software Integrity Group
For this model to work, the role needs to come with real incentives — recognition, career development opportunities, or dedicated time to pursue security learning — not just additional responsibility on top of an existing workload.
5. Embrace Automation — and Use It to Win Over Skeptics
One underappreciated reason cultural resistance to DevSecOps exists is that, at first glance, it looks like net-new work nobody asked for. Asking developers to “just do more security” without changing anything else is a reliable way to generate resentment. Automation is the answer to this objection.
Integrating automated static analysis, dynamic scanning, and runtime security checks directly into the CI/CD pipeline means security gates run without anyone having to manually trigger them. Security becomes part of the pipeline rather than an interruption to it.
“A lot of verification needs to be automated through the use of a combination of static, runtime, and chaos engineering tools to reduce the amount of grunt effort involved.”
Premand Chandrasekaran, Barclaycard
Automation also relieves the anxiety that developers will need to become security experts themselves. The goal is not for every engineer to define security policy — it is for security policies, defined by experts, to be encoded into automated tooling that everyone follows.
“It’s all about automation. The developer, the tester, the designer, the operations person — all need to be able to have responsibility for following security-relevant processes, not defining them. Once you have the processes in place, you can manage by exception: instead of trying to check that people do the right thing all of the time, spot when they do the wrong thing and sort it out from there.”
Mike Bursell, Chief Security Architect, Red Hat
The Bottom Line
DevSecOps is not primarily a tooling problem — it is a people and process problem. The three cultural obstacles outlined here (security as afterthought, organizational silos, and the speed-versus-security false dilemma) are deeply interrelated and tend to reinforce each other. Addressing them requires a combination of structural changes — embedding security into teams, launching champion programs, building training into the workflow — and technical enablers like pipeline automation that reduce manual toil.
The organizations making the most progress on DevSecOps are not the ones with the most sophisticated security tooling. They are the ones that have made security everyone’s shared responsibility, supported by automation that makes doing the right thing the path of least resistance.
This article draws on quotes originally published by enterprisersproject.com.