A Trust Problem With a Long History
The security-development tension is one of the oldest organisational dynamics in enterprise technology. Security teams experience developers as reckless: shipping code before it is tested for vulnerabilities, ignoring security requirements until they become blocking issues, treating security review as an obstacle rather than a quality gate. Developers experience security teams as blockers: slow to respond, focused on theoretical risk rather than practical delivery constraints, applying frameworks designed for a deployment cadence that predates CI/CD by a decade.
Neither characterisation is fair, and both reflect real experiences that have accumulated over years of genuine operational tension. The security team that has spent months remediating vulnerabilities that could have been caught in code review has earned its frustration with developers who bypassed the review. The development team that has watched a two-week release cycle halted by a security finding raised the day before deployment has earned its frustration with a security process that cannot operate at delivery pace.
DevSecOps as a concept was supposed to resolve this tension. In most enterprise organisations it has not. It has added security tooling to the delivery pipeline without changing the underlying relationship between the teams. The scans run. The findings appear. The priority disagreements continue. The trust has not been rebuilt.
Why Tooling Integration Is Not Enough
The premise of most DevSecOps implementations is that the security-development conflict is a workflow problem: if security checks are integrated into the pipeline, security and development will naturally converge because the feedback loop is faster and the findings are more actionable. This premise is wrong, or at minimum insufficient.
The conflict is not primarily a workflow problem. It is a risk ownership problem. Security teams are accountable for security outcomes. Development teams are accountable for delivery outcomes. When a security finding delays a release, the development team bears the cost of the delay and the security team bears the cost of a potential breach if the finding is deprioritised. These accountability structures create incentives that are structurally misaligned, and adding a security scan to the CI pipeline does not change the accountability structure.
The tooling integration also does not address the cultural distance between the teams. Security engineers and software engineers are trained in different disciplines, measure success by different metrics, use different vocabulary, and operate in different rhythms. A security scan finding described in CVE language and severity scores is not inherently interpretable to a developer who needs to understand what the finding means for their specific application and their specific release commitment.
Addressing the trust gap requires changing the accountability structure, the communication norms, and the shared ownership model. These are organisational changes, not tool configurations.
Shared Risk Ownership as the Foundation
The most effective structural change that enterprise organisations have made to the security-development relationship is establishing shared risk ownership. Instead of security teams owning security risk and development teams owning delivery risk, the redesign creates joint accountability for both dimensions.
In practice, shared risk ownership means that the development team’s success metrics include security outcome metrics alongside delivery metrics. Time-to-remediate critical vulnerabilities, reduction in new vulnerabilities introduced per deployment, and DAST finding severity trends become part of the delivery team’s performance picture, not just the security team’s. Simultaneously, the security team’s success metrics include developer experience metrics: response time on security reviews, false positive rate in automated scanning, and adoption rate of security tooling by development teams.
When the development team has a stake in security outcomes and the security team has a stake in developer experience outcomes, the adversarial dynamic shifts toward a collaborative one. Both teams have something to gain from the other team performing well. The joint accountability is not primarily a performance management mechanism. It is a signal about whose problem security is. The answer is: everyone’s.
Security Champions Embedded in Development Teams
Security champions programmes are not new, but most enterprise implementations treat them as a training programme rather than an organisational design decision. The security champion attends security training and brings security awareness back to the development team. This model improves security awareness without improving the security team’s understanding of development constraints, and without improving the speed and quality of security feedback for the development team.
The more effective model embeds security expertise in the development team as a standing capability rather than as a liaison from the security organisation. The security champion in this model is a developer with security depth, not a security specialist parachuted in. They participate in sprint planning, they review pull requests with a security focus, they escalate to the central security team for specialist input on specific questions, and they provide the translation between security requirements and development practice that reduces friction on both sides.
This model requires investment in developing security depth in development engineers, which is a skills development programme rather than a hiring programme. It also requires the security organisation to accept that security expertise distributed across development teams operates differently from security expertise concentrated in a central function, and that distributed expertise requires different governance and quality assurance mechanisms.
Security Requirements in Product Backlogs
Security requirements that arrive as blocking findings at the end of a release cycle are guaranteed to create conflict. Security requirements that are part of the product backlog from the beginning of a delivery cycle are significantly less disruptive and significantly more likely to be addressed with the care they require.
The mechanism for getting security requirements into the product backlog is threat modelling early in the delivery process. For each significant feature or architectural change, a lightweight threat modelling exercise identifies the security requirements that the feature creates: what data it handles, what trust boundaries it crosses, what authentication and authorisation requirements it introduces, and what the attack surface implications are. These requirements enter the backlog as acceptance criteria or as explicit backlog items, and they are planned into the delivery cycle rather than discovered at the end of it.
Threat modelling requires that security engineers engage with feature development at the planning stage, which requires earlier access and closer collaboration than most current processes provide. It also requires that security engineers develop enough understanding of the application and its development context to produce threat models that are specific rather than generic. The investment in this collaboration pays back in reduced rework and reduced conflict at deployment time.
Post-Incident Review as Relationship Architecture
How post-incident reviews are conducted shapes the security-development relationship as much as any process change. The traditional post-incident model identifies root causes, assigns blame, and documents lessons learned. In a security incident, this model typically assigns root cause to a developer who introduced a vulnerability and a security process that failed to catch it. Both conclusions are accurate and neither is productive.
Joint post-incident reviews that exclude blame allocation and focus on systemic improvement create a different dynamic. Security and development teams review the incident together, identify the points in the development, deployment, and detection process where the incident could have been prevented or detected earlier, and jointly own the process improvements that follow. Both teams leave the review with a shared understanding of what happened and a joint commitment to the changes that prevent recurrence.
Over time, the shared experience of investigating incidents together and improving the system together builds the kind of trust that tooling integration does not. Trust between teams comes from shared experience of solving hard problems, not from shared tools. The post-incident review, conducted well, is one of the highest-leverage relationship investments available to the security-development partnership.
The Cultural Change That Precedes Durable Progress
The process changes described above are necessary but not sufficient. Durable improvement in the security-development relationship requires a cultural shift that the process changes enable but do not automatically produce.
The cultural shift is from security as a constraint to security as a shared outcome. When security is experienced as something that security teams do to development teams, the relationship remains adversarial regardless of the process and tooling in place. When security is experienced as something that both teams do together, with different expertise contributing to a shared result, the dynamic changes.
Creating that cultural shift requires leadership behaviour on both sides. Security leadership that approaches development teams as colleagues rather than as non-compliant users of security policy. Development leadership that approaches security requirements as quality standards rather than as external constraints on delivery. These leadership behaviours are visible to the teams they lead, and they set the tone for every interaction between the teams.
The tools are already there. The process redesign is achievable. The cultural shift is the hardest part and the part that most DevSecOps programmes do not explicitly invest in. It is also the part that determines whether everything else holds.