This article draws on perspectives originally reported by Dark Reading (darkreading.com). Original publication date: August 7, 2019.
The Root Problem: Preconceived Notions on Both Sides
Security teams have long carried the reputation of being “out of process” — adding requirements, complicating workflows, and disrupting delivery velocity. At the same time, developers are frequently characterized as reckless engineers who treat security as someone else’s problem.
“In many organizations, the teams rarely interact, and the group reputation precedes the meeting. Security is ‘Dr. No’ and app dev is ‘rogue, ignoring security,'” says Matt Keil, director of product marketing at Cequence Security. “The reality is that building security into the development process — be it agile, DevOps, DevSecOps, or a mix thereof — remains a significant challenge for many reasons, beginning with the group relationship.”
These entrenched attitudes make integrating security into the software development life cycle (SDLC) an uphill battle. The solution may lie not in adopting a new acronym or tool, but in fundamentally reframing how organizations think about the problem.
Is Automation the Answer?
One commonly proposed fix is automation — embedding security checks directly into the CI/CD pipeline so they run without requiring manual intervention or cross-team handoffs. Matt Rose, global director of application security strategy at Checkmarx, argues this approach works precisely because it removes the friction of labels and separate workflows.
“When you integrate and use security as part of that automation associated with the DevOps pipeline and continuous integration orchestration, it works much better,” Rose says. “Automation at CI is the key aspect — the conductor of the symphony orchestra.”
Rose identifies four disciplines within a mature DevOps practice where security tooling can be embedded:
- Development: Static analysis (SAST), secrets scanning, and secure coding linting tools run in the IDE or pre-commit hooks.
- Continuous Integration (CI): Automated security tests — SAST, software composition analysis (SCA), and dependency checks — execute on every build.
- Continuous Delivery (CD): Dynamic analysis (DAST) and infrastructure-as-code scanning run against staging environments before promotion.
- Production: Runtime application self-protection (RASP), threat detection, and continuous monitoring provide ongoing visibility.
“You look at those building blocks, and there are different security technologies that slot themselves within each of those disciplines,” Rose says. “It’s about understanding where to integrate, but people make it much more difficult by putting different labels on security. When you look to architect a DevSecOps pipeline, you basically insert the right technologies at the right points in the DevOps process.”
The common “shift left” directive — catching vulnerabilities earlier in the cycle — is useful, but Rose argues it is incomplete. A healthy DevOps pipeline is a continuous loop, not a linear relay race, and security needs to be present at every stage, not just the earliest ones.
Where Does “Sec” Actually Fit In?
Since development and operations first converged to share responsibility and accountability, other business units — including security — have attempted to create their own derivative of the model. Kelly Shortridge, VP of product strategy at Capsule8, argues this is precisely where things go wrong.
“I think we need to discuss a DevOps-centric approach to security rather than trying to figure out a security-centric approach to DevOps,” she says. “SecDevOps is a vendor-driven term that gives a false sense of comfort for security teams so that it seems they are actually doing something to fit into the DevOps world.”
Shortridge’s point is that DevOps is fundamentally a mindset — a collaborative approach to optimizing software delivery and operational performance. Security teams that automate a handful of tasks and declare themselves “DevOps-enabled” are missing the deeper shift required.
“Security has to shift to thinking about how it can improve software delivery performance and how it can start unifying that responsibility and accountability,” she explains. “It takes a lot more work than what I’ve seen commonly, which is supporting the old threat models and controls with new technologies and trying to steamroll the DevOps team by trying to shove all the security testing into the software development life cycle.”
The biggest practical step, Shortridge says, is ensuring security priorities are aligned with business priorities — not just compliance checklists or internal audit requirements.
Changing the DevOps Narrative
The framing of “integrating security into DevOps” carries an implicit assumption: that DevOps teams do not think about security on their own. Julien Vehent, security engineering manager at Mozilla, pushes back on that assumption.
The “move fast and break things” culture so often associated with DevOps was, he explains, largely a symptom of early-stage startups operating with minimal risk exposure. Large enterprises adopting DevOps practices have a different risk profile entirely — they want speed, but they cannot afford to break things.
“These companies have adopted DevOps but have also made sure to integrate security in their quality assurance and testing processes to make sure that they can go fast without breaking things,” Vehent says.
This reframes the challenge: it is not that DevOps is inherently insecure, but that the cultural story told about DevOps has given security teams an excuse to position themselves as an external corrective force rather than embedded partners.
A Real-World Culture Change: The Malwarebytes Example
One of the more concrete examples of culture-driven change comes from Malwarebytes. Mark Patton, senior vice president of engineering at Malwarebytes, describes how the company addressed its DevSecOps gap not by purchasing new tooling, but by creating a dedicated team with a specific charter.
“At Malwarebytes, we did not have good SecDevOps until I created a group within engineering that had the specific charter of ensuring the ‘ops’ and ‘sec’ part of SecDevOps was owned and done properly,” Patton says. “We named the team ‘Site Reliability Engineering,’ and they were the bellwether team that changed the culture of engineering from within.”
The SRE team operated under a clear, memorable mantra: 100% uptime, 0% breaches, optimize cost. That three-part principle gave the team a framework for prioritization and a way to communicate their value to the broader engineering organization without resorting to security jargon.
In practice, the team:
- Reshaped how environments were provisioned and deployed.
- Reworked deployments to use more cost-effective AWS services.
- Showed developers how to architect cloud systems to balance security and cost.
- Implemented security monitoring that routed alerts directly to the appropriate owners.
The process was not frictionless — finding qualified talent and winning over skeptical engineers were both significant challenges. But Patton notes that the results eventually converted even the most reluctant team members.
Leave Your Ego at the Door
Ultimately, closing the gap between security and DevOps demands concessions from both sides. Security teams must be willing to relinquish manual gatekeeping in favor of automated controls that do not block delivery. Development teams must accept that security feedback is not an adversarial review but an enabler of sustainable velocity.
“Security teams need to be willing to loosen the security change control reins, allowing automation to play a larger role in their process,” Keil says. “Security teams also need to look outside of their existing toolset to ensure they have the right mix for their current and future application architectures.”
Jonathan Deveaux, head of enterprise data protection at comforte AG, frames the ideal outcome clearly: the shift to closer collaboration “promotes teams to move from viewing security inclusion as a blocker to instead viewing security as an enabler to getting their code into production.”
Key Takeaways for DevOps and Security Teams
- Culture precedes tooling. No security tool will bridge teams that do not communicate or share priorities. Address the relationship first.
- Embed security in the pipeline, not around it. Security gates that exist outside the CI/CD loop become bottlenecks. Automated checks that run inline become part of normal workflow.
- Align security priorities with business priorities. Security programs that cannot articulate their value in terms of delivery speed, uptime, and cost will remain marginalized.
- Avoid acronym proliferation. DevSecOps, SecDevOps, and similar labels can obscure the real goal: a single, integrated engineering culture where security is everyone’s responsibility.
- Change from within. As the Malwarebytes example illustrates, embedding security-minded engineers inside the engineering organization — rather than keeping them in a separate security silo — can be more effective than any top-down mandate.