📬 Mailbag: What's the best approach for sharing vulnerability findings with developers to avoid inciting defensiveness?

Mailbag questions are submitted anonymously by our readers. Submit your own question for our team at discernibleinc.com/blog.

Effectively communicating about security vulnerabilities with developers requires more than technical accuracy. When done poorly, security teams can inadvertently trigger defensiveness, create organizational silos, or delay critical fixes. But when done well, these interactions can build trust, foster collaboration, and strengthen relationships (read why this matters in our previous post about building influence here). 

The Communication Challenge

Security and product engineering teams often operate with different mindsets, priorities, and even languages (and that’s OK!). According to Schein's Organizational Culture Theory, distinct subcultures within the organization typically have their own assumptions and values. Most security teams prioritize risk mitigation, while product developers focus on feature delivery and user experience (to varying degrees of success all around).

This fundamental difference creates what Watzlawick's Interactional View would identify as a content/relationship paradox, meaning the "content" (vulnerability findings) becomes inseparable from the relationship between the communicating parties, making the exchange inherently emotionally charged. The consequences of emotionally charged interactions extend far beyond the immediate conversation. Emotional undercurrents can significantly impact organizational effectiveness and team dynamics. The theories and communication strategies outlined in this blog post aren’t specific to security teams, but they appear to be things most security teams aren’t using. 

Why do we care about emotionally charged interactions with cross-functional partners? Because they can cause the following: 

• Delayed remediation timelines – including questioning the validity of findings, deprioritizing security tickets, seeking excessive confirmation before acting, or requesting unnecessary documentation.
• Information filtering & distortion – when we receive information that conflicts with our self-image (such as "your code has security flaws"), we often unconsciously filter or distort that information to protect ourselves. 
• Trust erosion and communication breakdown – most professional relationships operate on reciprocity. When security communications feel like attacks, the natural response is to pull back from future exchanges.
• Knowledge transfer failure – organizations function best when team members can efficiently share knowledge and expertise. Emotionally charged exchanges disrupt this process, preventing the cross-pollination of information and experience across teams.
• Organizational politics and reputation damage – emotionally charged conversations rarely remain private. They become discussion topics with other people, shaping how entire teams perceive one another.

Security teams that consistently trigger defensive responses with emotionally charged conversations eventually realize that their input is sought later in the development cycle (when changes are costlier & messier), they're viewed as blockers rather than enablers. If their recommendations are implemented, they are usually done superficially rather than fully embraced.

3 Communication Theories That Inform Better Practices

Emotionally charged dynamics between teams (including security & developers) present a significant challenge, but communication research offers hope and direction. Understanding the psychological impact of vulnerability reporting is only the first step. The next step is translating it into practical communication strategies, where real transformation occurs. 

Drawing on established communication theories, security professionals can develop approaches that acknowledge emotional realities while effectively conveying critical security information. These theories provide more than conceptual frameworks but actionable suggestions for how security teams can reframe their messaging and structure interactions to build bridges rather than silos. The following communication theories offer particular value: 

Face Theory and Psychological Safety

Brown and Levinson's Politeness Theory (sometimes called the “Face Theory”) provides a useful framework here. The “face” in this theory refers to someone’s self-image and social identity, which can be threatened during social interactions. When developers receive vulnerability reports, both their "positive face" (AKA the desire to be appreciated and liked by others) and "negative face" (AKA the desire for autonomy and freedom from imposition) can feel threatened. Security professionals who acknowledge the skill and complexity of the developer's work before presenting findings demonstrate respect for both the positive and negative face.

This is important because, as Amy Edmondson's Psychological Safety research suggests, team members need to feel safe taking interpersonal risks for high-performance collaboration. Psychological safety increases when vulnerability findings are communicated as shared challenges rather than individual failures. Understanding how our approach or language can threaten someone's self-image and social identity helps us ensure the environment feels safe enough for them to engage in productive discussions.  

A particularly challenging situation happened with a client’s mobile app team during the final weeks leading up to a major release. The security team had discovered several critical API vulnerabilities and were hesitant on how to address this with product managers because historically, bringing findings to this developer team had been met with tension and pushback.

Instead of leading with the vulnerabilities as they typically would, we completely changed the security team’s approach. We scheduled a quick informal chat with their tech lead before the formal meeting and asked about their current challenges. They opened up about the immense pressure they were under – marketing had already announced the release date, they were struggling with unexpected iOS compatibility issues, and two team members were on leave.

When we gathered for the vulnerability review the next day, our client (a senior security engineer) started by acknowledging the situation. "Before we dive in, I want to recognize you're dealing with significant constraints right now – the announced release date, the iOS issues you mentioned yesterday, and being short-staffed. I know adding security concerns doesn't make that easier."

The air in the room immediately changed. Body language shifted from crossed arms and tense postures to more open engagement. Rather than immediately challenging the validity of security’s findings, they asked clarifying questions about the vulnerabilities. One developer even volunteered, "This actually connects to something we've been worried about in the payment flow."

What had previously been confrontational meetings transformed into a collaborative session where we jointly categorized which issues needed fixing before release and which could be addressed in the first update. By the end of the meeting, our client’s team was invited to the mobile team’s daily standups during the remediation period, which had never happened before.

The vulnerability fixes were implemented more thoroughly than we had expected. For the first time, the development team proactively reached out when they spotted a potential security concern in another area of code. This single shift in approach – taking the time to acknowledge their reality before presenting security’s findings – protected everyone’s positive and negative face, creating psychological safety conducive to honest and productive discussions.

Framing Theory and Loss Aversion

Prospect Theory tells us that people respond differently to information depending on whether it's framed as a potential gain or loss. Security findings traditionally emphasize potential losses (breaches, data theft, reputational damage, etc.), which trigger loss aversion and defensive responses. Reframing vulnerability communication around opportunities such as improving product quality, enhancing user trust, and developing more secure coding practices can shift this dynamic in a really powerful way.

I witnessed a powerful transformation when working with an e-commerce client's development team. After completing a thorough security assessment of their payment processing system, several vulnerabilities related to data encryption and input validation were discovered, which created potential injection attack vectors. Recognizing how traditional security reporting often triggered defensiveness, we deliberately reframed our approach for the findings presentation. Rather than using alarming language about vulnerabilities and risks, we titled the meeting "Payment Experience Enhancement Opportunities" and structured the conversation around business value.

We began by contextualizing security improvements within industry trends, showing where consumers increasingly consider security indicators when deciding whether to complete purchases, and that visible security measures can positively impact conversion rates. This shifted the conversation upfront from preventing theoretical losses to gaining competitive advantages. 

When addressing the encryption findings, we presented it as an opportunity to implement industry-leading protection that could be promoted to users as a differentiating feature. We highlighted how companies emphasizing security measures in checkout flows often see improved completion rates and customer retention. We emphasized the dual benefits of security and user experience for the input validation issues. We noted how proper validation would prevent attacks while catching common user input errors, reducing customer frustration and support requirements. We provided examples of leading payment processors successfully transforming similar security improvements into marketable trust-preserving features.

As a result, the development team's response was different from their previous reactions to security findings. Instead of reacting defensively, the conversation turned to implementation options and best practices, focusing on how these improvements could be highlighted in the user experience rather than treating them as invisible technical requirements.

What began as potentially uncomfortable security findings became a collaborative planning session for enhancing their product. The team implemented the security fixes promptly, and we then worked with their marketing department to highlight these security enhancements in their release communications and checkout interface. 

In subsequent development cycles, the team began proactively consulting our client during feature planning, approaching security as an integral part of product quality. This experience demonstrated how reframing security communication (from loss prevention to opportunity creation) can transform the entire development relationship and ultimately lead to more secure, successful products.

Dialogic Communication

Buber's Dialogic Communication Theory suggests moving from treating people as mere recipients of information to recognizing them as partners in solving a shared problem. This shift from one-way transmission to true dialogue fundamentally transforms vulnerability communication. 

Here are a few examples of how this theory works in practice:

Mutual Exploration vs. Declaration

Traditional Approach: Security presents findings as definitive declarations, with developers expected to implement the recommended solutions.

Dialogic Approach: Findings become starting points for joint exploration where both security and development expertise are valued.

• Beginning with open questions: "What do you see when you look at this code pattern?"
• Using genuine inquiry: "What constraints might make addressing this challenging?"
• Acknowledging limitations: "I understand how the authentication system works, but I'd value your deeper perspective on it."
• Co-creating solutions: "Let's think together about approaches that meet both security needs and your performance requirements."

Embracing the "Between Space"

Traditional Approach: Each team maintains rigid boundaries and speaks from their specialized domains without empathy for the other's world.

Dialogic Approach: Security professionals intentionally step into a shared conceptual space where neither security nor development perspectives dominate. 

• Use inclusive language: "The challenge we're facing" rather than "The vulnerability you've created."
• Create tangible "between spaces" like shared whiteboards or online collaboration tools, where both teams contribute.
• Develop shared vocabularies that bridge security and development 
• Establish regular cross-functional sessions dedicated to security topics

Reciprocal Vulnerability

Traditional Approach: Security teams position themselves as authoritative experts, rarely acknowledging their own knowledge gaps or uncertainties.

Dialogic Approach: Security professionals model vulnerability by:

• Openly acknowledging the limitations of their technical understanding
• Sharing stories of their own security mistakes or learning experiences
• Asking for help understanding complex development considerations
• Admitting when a security recommendation might need refinement based on development insights

Standing With, Not Against

Traditional Approach: Security positions themselves as inspectors or auditors standing in judgment of development work.

Dialogic Approach: Security professionals position themselves alongside developers facing shared challenges:

• When in-person, physically sitting on the same side of the table during discussions
• Using "we" language when discussing both problems and solutions
• Establishing shared metrics for security success
• Jointly presenting security wins and challenges to leadership
• Attending each other's regular team meetings to build relationship continuity

When security teams shift from transmitting information to engaging in a two-way dialogue, the entire communication dynamic improves. Developers move from passive recipients who must be convinced of something to active co-creators who bring their valuable insights to security challenges. The "us versus them" mentality dissolves into a shared accountability model.

Practical Approaches Based on These Theories

1. Build Shared Mental Models

Communication effectiveness increases when everyone shares an understanding of the situation. Create this shared foundation by developing a common security vocabulary that translates security concepts into developer-friendly terms, conducting collaborative threat modeling sessions where both teams map risks together, connecting vulnerabilities to business impacts rather than focusing solely on technical details, and establishing learning feedback loops that review successes and failures. 

When security and development operate from the same mental model, vulnerability discussions become less about education and more about collaboration toward shared goals.

2. Establish Communication Rituals

Consistent communication patterns reduce uncertainty and build trust between teams. Implement regular touchpoints like security office hours and recurring vulnerability reviews, standardize reporting formats with clear severity rubrics and contextual information, create cross-team rituals such as security retrospectives and joint presentations to leadership, and establish recognition systems that celebrate security achievements. 

These predictable communication patterns create psychological safety, allowing vulnerability discussions to become normal, expected interactions rather than anxiety-inducing confrontations.

3. Focus on the Problem, Not the Person

Security findings often trigger a fundamental attribution error – attributing vulnerabilities to the developer's skill rather than situational factors like deadlines or technical constraints. You can avoid this pitfall by using language that separates code from identity ("This function lacks validation" vs. "You didn't validate inputs"), acknowledging systemic factors and constraints that contributed to the issue, focusing on future prevention rather than past mistakes, and humanizing the process by sharing your own learning experiences. The goal is to avoid making vulnerability discussions feel like personal criticism by turning them into collaborative problem-solving.

4. Promote Reciprocal Conversations

Effective communication is never one-way. So, actively solicit feedback on your communication approach, inquire about development constraints before proposing solutions, practice deep listening to understand rather than simply respond, and acknowledge when security requirements create legitimate challenges for development teams. This demonstrates respect for developers' expertise and creates the conditions for genuine partnership, where security becomes a shared opportunity rather than an imposed requirement.​​​​​​​​​​​​​​​​

If you want to learn more about Discernible’s security communications work and how we can help your team improve cross-functional influence, contact us here.