Security teams and developers often share the same goal: building reliable, secure systems. Yet in many organizations these teams frequently find themselves in frustrating conversations about risk.

A security team flags a vulnerability as “high risk,” while the developer who built the system responds with a familiar explanation: “But that’s how it’s supposed to work.”

Both perspectives can be technically correct. Developers are focused on functionality, performance, and delivering features. Security teams evaluate the same system through a completely different lens that considers exploitability, data exposure, threat actors, and potential business impact. When those perspectives collide, communication breaks down and teams struggle to move forward.

This session explores why these conversations happen and why security and engineering teams often interpret the same system behavior in very different ways.

Through practical examples and real-world inspired scenarios, we will walk through how common development patterns can introduce security concerns even when the system behaves exactly as designed. We will examine how security teams assess risk, why certain issues escalate quickly, and how misunderstandings about threat models and system behavior create friction between teams.

Rather than focusing on tools or frameworks, this talk focuses on the human and organizational side of DevSecOps. Attendees will gain insight into how security teams evaluate risk, why some vulnerabilities become major incidents while others do not, and how developers and security professionals can collaborate earlier in the development lifecycle.

By understanding how both sides approach security challenges, teams can move beyond friction and build stronger partnerships that lead to more resilient software systems.