This article is based on first-hand observations originally published on Dark Reading, written from the perspective of an experienced security professional attending DevOps World, a conference hosted by CloudBees.
Why Security and DevOps Still Don’t Speak the Same Language
Attending a major DevOps conference as a career security professional is a revealing experience. The culture, priorities, vocabulary, and daily pressures of DevOps engineers can feel alien to someone who has spent years in security — and vice versa. Yet the two disciplines are increasingly interdependent. As organisations push security checks earlier into the software development lifecycle (the “shift left” model), the friction between security teams and pipeline owners is becoming a genuine business risk.
The observations below, drawn from candid conversations with DevOps engineers at a dedicated DevOps conference, offer security professionals a clearer picture of how their developer counterparts think about security — and what practical steps can help close the gap.
1. Admit That Security Has a Perception Problem
Many DevOps engineers at security-conscious organisations are actively looking for ways to ship code to production faster. When security gates slow that process down, security teams get labelled as a bottleneck — not a partner. This perception is not always fair, but it is real.
The encouraging news is that many DevOps engineers genuinely want to solve the security problem. The discouraging news is that they often don’t know where to start. This gap is an opportunity for security leaders to step in with concrete tool recommendations and an honest conversation about what security testing inside a CI/CD (continuous integration and continuous delivery) pipeline actually requires.
Starting from a position of empathy — rather than authority — makes that conversation far more likely to succeed.
2. Teach the ABCs of Security Tooling
DevOps engineers often have surface-level familiarity with security product names but struggle to distinguish between fundamentally different tool categories. For example:
- Static Application Security Testing (SAST) — scans source code for vulnerabilities before the application runs.
- Dynamic Application Security Testing (DAST) — tests a running application from the outside, simulating an attacker.
- Software Composition Analysis (SCA) — identifies known vulnerabilities in open-source libraries and dependencies.
- Container security scanning — inspects container images for vulnerable base layers, misconfigurations, and embedded secrets.
- Infrastructure-as-Code (IaC) scanning — checks Terraform, CloudFormation, and similar files for security misconfigurations before deployment.
Security teams that can map these tool categories to specific stages in a DevOps pipeline — and explain the trade-offs in plain language — become far more useful advisors than those who simply demand compliance.
There is a reciprocal obligation here: security practitioners need to learn DevOps vocabulary. Knowing the difference between a Jenkins pipeline stage and a GitHub Actions workflow, or understanding what “breaking the build” means in practice, signals credibility and earns a seat at the table.
3. Acknowledge the “Get Security Off My Back” Mindset
There is often a genuine cultural tension inside engineering organisations: DevOps teams are measured on release velocity and uptime, while security teams are measured on risk reduction. These incentives can point in opposite directions.
Rather than fighting this dynamic, security teams can work with it. Practical approaches include:
- Negotiating placement of scans — agree on which security checks happen inside the pipeline and which happen in a parallel or post-release workflow, so critical scans don’t add latency to every commit.
- Pre-release code scanning — run SAST and SCA checks before a pull request is merged rather than as a blocking gate on deployment.
- Post-release live testing — schedule DAST or penetration testing against staging or production environments outside of peak release windows.
- Incremental adoption — start with a small number of high-value, low-friction checks. Build trust before expanding scope.
Demonstrating that security did not slow a release cycle — or that it caught a real vulnerability before it reached production — builds the kind of credibility that makes future conversations easier.
4. Never Break the Build Without a Plan B
One of the most pointed pieces of feedback heard from DevOps engineers on security tooling is a simple principle: when in doubt, rip it out. If a security scanner causes a pipeline to fail unpredictably, engineers will remove it — with or without security team approval.
This is not a hypothetical risk. Automated vulnerability scanners can produce false positives, time out under load, or fail to connect to upstream threat-intelligence feeds — all of which can halt a build. Security teams that introduce tools into pipelines without a contingency plan lose trust fast.
Best practices for avoiding this outcome include:
- Run security tools in “audit” or “warn” mode initially — report findings without blocking the pipeline until confidence in the tool’s accuracy is established.
- Define a clear escalation path for failures — if a scanner goes down, the pipeline should continue with an alert sent to the security team, not a hard stop.
- Agree on severity thresholds in advance — only critical or high-severity findings should block a release; medium and low findings should be logged for triage.
- Test the scanner itself in a staging pipeline — before requiring it in production workflows, validate that it performs reliably under real load.
A security tool that engineers trust to behave predictably is one that stays in the pipeline long-term.
Building a Shared Security Culture
The gap between security and DevOps is not primarily a technology problem. It is a culture and communication problem — one that requires security professionals to invest time in understanding how DevOps teams work, what pressures they face, and how security can be positioned as an enabler rather than an obstacle.
The practical steps are straightforward: learn the vocabulary, pick tools that fit the workflow, negotiate placement rather than mandate it, and never introduce a security gate without understanding what happens when it breaks. Done well, DevSecOps is not a compromise — it is a force multiplier for both speed and safety.
Security professionals who make the effort to cross the cultural divide will find a much more receptive audience on the DevOps side than the initial friction suggests.