This article is based on a piece originally published at enterprisersproject.com, drawing on insights from security and DevOps practitioners.
The New Silo Nobody Planned For
A strange thing happened as organisations adopted DevOps and dismantled the old walls between development and operations teams: many built a new wall around security instead. DevOps improved collaboration in one part of the organisation while leaving security teams more isolated than ever.
Pete Cheslock, then senior director at Threat Stack, summed up the problem: “We found through our research that DevOps and security teams are already operating in silos, and the rush to the cloud is exacerbating this disconnect. Teams are increasingly isolated, and they’re facing a steep learning curve.”
Red Hat security strategist Kirsten Newcomer put it plainly: “Security teams have historically been isolated from development teams – and each team has developed deep expertise in different areas of IT.”
This is the problem DevSecOps is meant to solve. It is not just a rebranding exercise. In an environment defined by cloud infrastructure, containers, and relentless deployment pressure, treating security as an afterthought—or as someone else’s problem—is a meaningful operational and business risk.
As Cheslock notes: “To reduce risk without taxing resources, DevOps principles need to be applied to security practices too.”
Getting there requires more than buying new tools. It requires changing how people think, collaborate, and share responsibility. Below are six practical strategies for building genuine DevSecOps buy-in.
1. Make It About People First, Tools Second
The most common mistake teams make when launching a DevSecOps initiative is treating it as a tooling problem. Integrating a static analysis scanner or a dependency checker into a CI/CD pipeline is useful—but it does not, by itself, create a security-conscious culture.
Mike Kail, then CTO and co-founder at CYBRIC, is direct on this point: “DevSecOps is not about tools. It’s about establishing the culture where the security team is a collaborative member of the software development life cycle and CI/CD pipeline.”
The cultural challenge mirrors what DevOps itself faced: different teams optimising for conflicting incentives. Developers are measured on shipping velocity. Security teams are measured on risk reduction. Left unaddressed, these incentives pull in opposite directions.
Cheslock advises focusing on shared goals: “We need shared goals across teams in order to encourage collaboration.”
Lucky Johnson, then ESM senior architect at AHEAD, frames it this way: “The development mindset needs to see the value in adding security in lieu of delivery expectations. Getting the team to understand the core responsibility of each other and how each can benefit from the other is a key success factor.”
Practical starting points:
- Include security representatives in sprint planning and retrospectives, not just incident reviews.
- Define security objectives that are expressed in terms developers and operators recognise—build time, deployment frequency, mean time to remediate.
- Avoid making security purely a gate that stops work; make it a shared input into how work is scoped.
2. Empower Security Professionals to Lead the Culture Change
Sam Bisbee, then CSO at Threat Stack, offers a useful reframe for security practitioners: the burden of bridge-building falls on you first.
“As a security professional, you must realise that most non-security professionals have either had no experience or generally negative experiences with security teams. You will have to start building the bridges yourself.”
This means actively reducing friction rather than waiting for other teams to adapt. If operations has established processes and tooling, security should try working within those systems before proposing changes. When changes are necessary, the value proposition needs to be explicit and easy to understand.
Bisbee also highlights a productive tactic: find genuine common ground between security and other teams. As an example, both security and operations teams dislike direct logins to production servers—though for different reasons. Operations dislikes it because of availability and performance risk; security dislikes it because of audit and compliance exposure. Surfacing that shared concern creates a natural starting point for collaboration.
He also recommends that security professionals occasionally assist with availability incidents. Helping with an outage that has nothing to do with a CVE builds trust and mutual respect across teams.
Kail adds that the security team itself needs to be aligned internally before approaching other functions: “The security team needs to be internally aligned around the strategy for implementing security testing into the SDLC, and then meet with the development team to present that framework. It’s important to articulate the fact that this won’t be disruptive to developer velocity and that they will only have to change behaviour if there are any vulnerabilities to remediate.”
3. Introduce Security Champions on Product Teams
“Security is everyone’s responsibility” is a principle worth holding—but as a practical mandate it can backfire. When responsibility is distributed equally across everyone, it often falls to no one in particular. A more effective model assigns a higher degree of security responsibility to specific individuals embedded in each product or application team.
The Open Web Application Security Project (OWASP) defines the security champion role as follows:
- Security champions are active members of a team who help decide when to engage the central security team.
- They act as the primary “voice” of security for a given product or team.
- They assist in triaging security bugs relevant to their team or area.
This model scales security expertise without requiring every developer to become a security specialist. The champion acts as a translator and escalation point between the product team and the dedicated security function.
Security practitioner Alexander Antukh, then head of product security at Opera Software, developed a Security Champions Playbook to give organisations a concrete starting framework. It is available on GitHub and provides templates and guidance for standing up a programme.
4. Align Incentives and Metrics Across Teams
Culture change without structural reinforcement tends not to stick. If the performance metrics developers are evaluated against do not include any security dimension, the cultural message that “security is everyone’s job” will ring hollow.
Consider introducing shared metrics that cross functional boundaries:
- Mean time to remediate (MTTR) for vulnerabilities — tracked alongside deployment frequency so teams see the trade-off clearly.
- Security debt — quantified and visible in the same backlog as technical debt.
- Percentage of builds passing security gates automatically — a positive metric that rewards proactive work rather than only flagging failures.
When security outcomes appear in the same dashboards and planning conversations as delivery outcomes, teams naturally start treating them with the same urgency.
5. Shift Security Left—Without Blocking Developers
“Shift left” is the principle of moving security checks earlier in the development cycle rather than reserving them for a final pre-production gate. This reduces the cost of finding and fixing issues, since a vulnerability caught in a pull request is far cheaper to address than one found in staging—or in production.
Practically, this means integrating automated security tooling into the developer workflow:
- Static application security testing (SAST) — runs in the IDE or as a pre-commit hook to catch common code-level issues immediately.
- Software composition analysis (SCA) — scans dependencies for known vulnerabilities as part of the build process.
- Container image scanning — checks base images and installed packages before images are pushed to a registry.
- Infrastructure-as-code scanning — validates Terraform, CloudFormation, or Kubernetes manifests against security baselines before deployment.
The key—as Kail noted—is that most of these checks should be invisible to developers who are not introducing issues. Only actionable findings should interrupt a workflow. Noisy, low-signal alerts are one of the fastest ways to erode DevSecOps buy-in.
6. Run Cross-Functional Training and Threat Modelling Sessions
Technical tools and process changes work better when people understand the underlying reasoning. Structured training that brings security, development, and operations staff together serves two purposes: it builds security knowledge across the organisation, and it builds relationships between teams that might otherwise rarely interact.
Threat modelling workshops are particularly effective for this. A structured threat modelling session—using a methodology such as STRIDE or PASTA—asks teams to identify what assets they are protecting, what could go wrong, and what controls are already in place. Running this exercise with a mixed group of developers, operators, and security engineers exposes each group to how the others think about risk.
Other cross-functional learning formats that have worked in practice:
- Security office hours — a regular, informal slot where developers can ask the security team questions without raising a ticket.
- Capture-the-flag (CTF) events — hands-on security challenges that developers and operators can participate in alongside security specialists.
- Post-incident reviews with security included — treating every significant incident as a learning opportunity for all functions, not just the team that was paged.
The Bottom Line
DevSecOps is not a product you buy or a job title you add. It is a shift in how development, operations, and security teams relate to one another and share accountability for secure, reliable software delivery. The technology matters—but it follows the culture, not the other way around.
Start with people. Identify your security champions, align your incentives, build your bridges, and then layer in the automation that makes security friction-free at scale. Organisations that take this order seriously tend to find that the tools become far more effective once the culture is ready to use them well.