This article is based on analysis originally published at darkreading.com.
The DevSecOps Gap
The security community talks constantly about DevSecOps—look at any vendor’s marketing materials. Yet very few organizations are suggesting, let alone implementing, significant changes to the way security work is actually practiced. DevOps represents a fundamental shift in how we think about building software, aimed at dramatically improving both speed and quality. At its core, DevOps prescribes three things:
- Get work flowing by breaking it into small, manageable pieces
- Create tight feedback loops so problems surface quickly
- Foster a culture of continuous innovation and learning
The exact problems that once plagued software delivery are still major problems for security. Most organizations perform security reviews on only a subset of their codebase—typically “critical” or “externally facing” applications—leaving vulnerability backlogs rampant across the broader portfolio and attack surface visibility close to zero.
A handful of persistent myths make this situation worse. Here are five of the most damaging ones, and what a more honest assessment looks like.
Myth 1: “DevOps Is All About Automation”
Automation is the most visible part of DevOps, and for security practitioners who have limited exposure to modern delivery pipelines, it may appear to be the whole story. In reality, automation is a means to an end, not the end itself. The deeper purpose is to make work visible, repeatable, and improvable.
The more productive framing for security teams: automation can also explain how a software factory actually works—where code moves, who approves it, and what gates it must pass through. Challenge security practitioners to experiment with applying DevOps techniques to their own workflows. Help them start their own DevOps journey rather than observing development’s journey from the sidelines.
Myth 2: “We Just Need to Shift Security Left”
“Shift left” is a catchy phrase that has become almost meaningless through overuse. Too often it simply means pushing legacy security tools—designed for a different era of software delivery—onto developers who lack the background to interpret or act on the results effectively.
A better approach is to help developers find modern security tools that:
- Integrate natively into the DevOps pipeline (CI/CD, IDEs, pull request workflows)
- Produce accurate, low-noise, actionable results
- Are genuinely designed for developer workflows, not repurposed from traditional security tooling with a new coat of paint
The goal is for security teams to recognize that security itself can undergo the same kind of DevOps transformation that development has—and enjoy the same gains in speed, coverage, and reliability.
Myth 3: “Increasing Velocity Reduces Security”
This myth conflates speed with sloppiness. Security quality doesn’t have an inherent relationship with delivery velocity. What high-velocity DevOps teams actually do is build automated quality checks—including security checks—into every stage of the pipeline, so that defects (including vulnerabilities) are caught far earlier and more reliably than in slow, manual processes.
The same automation and continuous feedback loops that produce high-quality software can be leveraged by security to deliver assurance faster and more consistently. DevOps establishes the infrastructure—automated pipelines, infrastructure-as-code, observable systems—that security teams have lacked for years. Turning security policies into code means organizations can dramatically increase the speed, coverage, and accuracy of their security efforts.
Myth 4: “DevOps Makes Security Harder”
Many security professionals are already overwhelmed by the scale and complexity of their challenge. When DevOps arrives, it can look like yet another set of moving parts to secure. Some security team members may—often unintentionally—slow, derail, or undermine a DevOps transformation as a result.
The antidote is inclusion, not confrontation. Bring security teams into DevOps planning early. Give them exposure to the development workflow. Widely recommended resources like The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford can help security practitioners understand the DevOps worldview and see their own work through a systems-thinking lens. Regular, structured interaction between security and development teams builds the shared vocabulary needed for genuine collaboration.
Myth 5: “Developers Don’t Care About Security”
This is one of the most damaging myths in the DevSecOps conversation. In practice, developers are generally curious and motivated people who want to build things that work correctly—and that includes securely. The problem is rarely developer indifference.
In many organizations, security requirements are poorly defined, inconsistently enforced, and function as a set of unpredictable landmines that can derail projects or damage careers. When developers avoid engaging with security, it is usually a rational response to a dysfunctional system, not a sign of apathy.
A more effective approach is to embed with development teams, make security requirements explicit and unambiguous, and automate checks so that a “clean” build can proceed to production at whatever velocity the team requires. Remove the ambiguity and most developers will engage readily.
Moving Beyond Security Exceptionalism
DevOps has delivered measurable improvements across a wide range of organizations and problem domains. It’s time to move past superficial “shift left” conceptions of DevSecOps and take a clear-eyed look at how security work actually gets done today: massive bottlenecks, duplicated effort, feedback loops measured in weeks or months, and wasted capacity.
Security exceptionalism—the idea that security is so uniquely complex that the principles governing every other part of software delivery don’t apply—is holding the field back. The vast majority of security work addresses well-understood vulnerability classes: injection flaws, path traversal, cross-site scripting, insecure deserialization, and similar problems that have documented mitigations. These are engineering problems. DevOps thinking, applied rigorously to security, can radically improve both the speed and the reliability with which they are addressed.
Key Takeaways
- DevOps is about culture and systems thinking, not just tooling and automation.
- “Shift left” only works if developers get tools and context they can actually use.
- Velocity and security are not inherently in conflict; automated pipelines can enforce both simultaneously.
- Security teams need to be included in—not consulted after—DevOps planning.
- Developers want to build secure software; the environment must make that achievable.
- Applying DevOps principles to security work itself—small batches, tight feedback, continuous improvement—is where the real gains are.