There’s a meeting that happens in almost every organisation with both a security team and a development team. Someone from security presents a list of findings. The developers sit there, arms folded — literally or figuratively. The findings get acknowledged, maybe assigned, and then nothing happens for weeks. Or months. Or ever.
Security blames dev for not prioritising fixes. Dev blames security for not understanding the codebase, the release schedule, the business context. Management watches both sides and decides the solution is a new policy, a new tool, or a new process that neither side asked for and neither side will use.
I’ve been in that meeting more times than I can count. On the security side of the table, holding a report full of findings, watching the room tune out.
The thing nobody says out loud: most of the friction between security and development teams has nothing to do with the technical findings. It’s about how the relationship is set up from the start.
How the relationship gets broken
The default setup in most organisations looks something like this. A security team – internal or external – runs an assessment. They produce findings. Those findings arrive on the developer’s desk as a list of things they did wrong. No context about the codebase. No understanding of why the code was written that way. No suggested fix. Just a severity rating and an expectation to prioritise it above whatever they were already working on.
From the developer’s perspective, security is a function that shows up periodically, criticises their work, and leaves. It doesn’t help. It doesn’t build anything. It doesn’t ship alongside them. It just produces problems.
From the security team’s perspective, developers don’t care about security and never prioritise remediation. So the next assessment gets escalated harder – more critical findings, more urgent language, more red in the charts. Which makes the developers tune out even more. Both sides end up convinced the other is the problem.
Frameworks exist to fix this. Shared responsibility models. DevSecOps maturity assessments. Secure development lifecycle documentation. They work on paper. In practice, you can’t document your way out of a trust deficit.
Where I saw it break – and mend
At one client, the first call between the security team and a lead developer was adversarial. Not just cold or distant. Heated. The developer had been through years of security assessments that amounted to someone dropping a list of problems on his desk and disappearing. He was done being polite about it.
That engagement ran for over a year. Within six months, that same developer and I were friends. Not colleagues-who-tolerate-each-other friends. Actual friends.
What changed wasn’t a new policy or a better framework. What changed was how we showed up.
Every finding raised as a ticket came with a suggested fix. Not “you should sanitise input” – actual code suggestions, specific to their codebase. When we wrote threat models, we wrote them together with the dev team, not for them. Architecture diagrams were built collaboratively, not handed down. Security policies – when they were needed – were drafted with developer input. Developers approved them because they’d helped write them.
The framing was never “here are your security problems.” It was “here’s what we’re going to fix together.” First person plural. Always. When a developer sees a ticket that says “we need to address this XSS” instead of “your application has an XSS vulnerability,” the conversation starts differently. And where that conversation happens matters just as much – findings that live in the same ticketing platform where the developer tracks their sprint get treated as work items. Findings that live in a PDF on someone’s shared drive get treated as someone else’s problem.
Over the course of that engagement, the security posture across the codebase changed fundamentally. Not because we ran a scanner and filed tickets. Because the developers started writing secure code as a matter of course. They understood the why behind each class of vulnerability. They’d been part of building the policies and practices, so they followed them – not because compliance required it, but because it made their own code better.
The same problem, different shape
At another client – a large enterprise – the friction looked different on the surface but the root cause was identical.
Their DevOps and security operations teams were locked in a blame cycle. Vulnerabilities were found, tickets were filed, nobody took ownership. DevOps said it was a security problem. Security said DevOps wasn’t remediating. Both teams produced documentation that justified their position. Leadership saw two teams pointing at each other and assumed the solution was more documentation, more frameworks, more process.
The internal transformation team had already accumulated multiple copies of vendor reports and a stack of frameworks that had never been operationalised. The documentation was technically sound. It just hadn’t changed anything.
The approach that worked was simpler than anyone expected. Build the vulnerability management workflow on the platform both teams already use. Not a separate system. Not a new tool. The platform they open every morning. Findings go into the same board where their work items live. Severity gets adjusted for business context, not just CVSS scores. Both teams see the same tickets, track the same progress, and own the same outcomes.
The client presented to their leadership that, for the first time, DevOps and security operations were working in collaboration. Their exact words for it: “getting shit done.” Internally, this wasn’t treated as a process improvement. It was treated as a cultural shift.
What actually breaks the pattern
Both engagements started with the same underlying problem and arrived at a version of the same solution. I don’t think the solution is a methodology you can package. It’s a posture.
Showing up with fixes, not just findings. The gap between “what’s wrong” and “what to do about it” is where most of the friction lives. A title, a severity, and a generic remediation suggestion leaves the developer to figure out the hard part on their own. A suggested fix – specific to their codebase, their framework, their constraints – turns a criticism into a contribution.
Writing policies with, not for. Security policies that get imposed top-down get followed the way speed limits get followed – technically, reluctantly, and only when someone’s watching. Policies that developers helped draft get treated as shared agreements. The difference is ownership.
Making it a “we” problem. If a consultant frames every finding as the client’s deficiency, the relationship is transactional from day one. Same finding, same severity – but “we have a problem in this module” lands completely differently from “your application has a vulnerability.”
None of this is complicated. All of it requires giving up the idea that security’s authority comes from being the team that says “no.” The gatekeeper role has power. Trading it for “let me help you get this right” feels like losing leverage. But it’s the only posture I’ve seen produce results that last beyond the engagement.
What this costs when it doesn’t get fixed
Most organisations tolerate dev-sec friction as a fact of life. Security and development don’t get along – that’s just how it is.
But the cost is real and measurable. Findings that sit unremediated for months. Developers who learn to treat security tickets as low-priority noise. Security teams that escalate harder, which makes developers disengage further. Repeat assessments that find the same issues because nothing got fixed since the last one. Reports that grow longer each cycle while the actual security posture stays flat.
The engagement I mentioned earlier – the one that started with a heated phone call – ended with fewer confirmed issues than repositories in the codebase. The difference wasn’t better tools or more assessments. It was two teams that learned to work together instead of around each other.
That started with one phone call that nearly went sideways, and one decision to show up differently.
Uncategorized 
Leave a comment