The Human Side of Security: Prioritizing People, Trust, and Communication

In this fast-paced world of application development, we constantly hear about technical debt, vulnerabilities, and the urgent need to manage risk. Yet, the real challenge lies beyond these technical issues—it’s about people, priorities, and the way we communicate. People and their knowledge are the most effective form of preventive control.

In this blog, I will delve into the importance of effective communication, the nuances of risk assessment, and how creating a cooperative environment between security teams and developers can lead to a more secure, efficient product and harmonious organization. 

The Communication Gap

One of the most significant barriers we encounter is how we communicate risk and vulnerabilities. Terms like "risk" and "vulnerability" inherently carry negative connotations. When we tell someone that their work has introduced a vulnerability, it's natural for them to become defensive.

This defensiveness can extend the time to remediate vulnerabilities unnecessarily, inflating or underestimating the associated risk. To overcome this, we need to shift our focus from merely identifying problems to effectively communicating them in a way that resonates with developers and technologists.

If security teams operate separately from the rest of the business, they end up dictating issues without bridging the communication gap. It's crucial to communicate in a way that aligns everyone on the same page.

Shifting the Risk Perspective 

The most widely adopted formula to calculate risk is impact times likelihood. Security teams often focus on the impact of a vulnerability but face challenges in reaching a consensus on its likelihood unless the vulnerability is exploited during penetration testing or dynamic scans. Realistically, pen-testing every component isn’t feasible due to limited resources. Yet, the security team is still expected to demonstrate exploitability, effectively reducing a probability percentage to a binary answer: exploitable or not.

Therefore, instead of communicating solely on likelihood, we can emphasize our confidence levels. Confidence levels provide a more adaptable and realistic perspective based on the collection of data, and insights from multiple techniques and technologies. For example, if a known vulnerable open-source component is proven reachable by your SAST and SCA tools, has mature exploit kits circulating in the wild, and threat intelligence indicates ongoing exploitation campaigns against it, it could have a high likelihood of being exploited—even with a lower CVSS/EPSS score.

This approach gives a better understanding of potential exploitation, another way to prove this is worth their time to act on. A confidence level is based on our visibility today, reflecting the current understanding and circumstances. Transparency and facts are the most powerful tools that security teams can use to communicate with development teams and earn their trust.

By focusing on confidence levels, security teams can give the development team a better idea of the current situation, allowing them to participate in the process. Developers can then work proactively to either increase or decrease that confidence level by improving or adapting their code and practices. This creates an opportunity for collaboration, enabling both teams to work together towards common security goals. 

Communicating and Collaborating with Developers for Better Security

Security isn't about pointing out developers' flaws—it's about empowering them. We can shift away from saying, "I'm here to help," which, while well-intentioned, can be perceived as "I'm here to correct your mistakes," and may come off as patronizing. Instead, the focus should be on enabling and empowering developers. This involves listening to their needs, acknowledging their passion, understanding their product, relating to their challenges, and equipping them with the right tools, resources, and processes that align with their needs and maturity level to enhance security within their workflows. Developers understand their products better than anyone else and security teams can offer insights into threats and vulnerabilities. This cooperative learning approach builds trust and fosters a culture of security.

Building trust and relationships with development teams doesn't show immediate results in metrics, and it seems time-consuming and exhausting, but it's essential for long-term success. The usual security metrics focus on vulnerabilities found, fixed, and remediated. However, these metrics don't capture the essence of building a collaborative culture. 

We need to understand that metrics often reflect symptoms rather than root causes. Just like how a doctor measures vital signs such as heartbeat and oxygen levels to assess a patient’s health, security metrics can indicate where we stand but do not solve the underlying issues. Treating security problems requires more profound, sustained efforts, much like addressing the root cause of a health problem.

We often hear that we should treat the cause, not just the symptom, but how often do we apply this principle in security? For example, if our time to remediate is 200 days, the common response is to pressure senior leadership to prioritize it, perhaps by emphasizing legal or compliance requirements. But this approach merely addresses the symptoms, not the root cause. Building positive relationships with developers is not just about fixing immediate issues but about understanding the bigger picture and working toward a long-term solution.

Communicating with Management

Senior management cares about the bigger picture. Reporting to management requires aligning security strategies with business objectives. Key Performance Indicators (KPIs) and Key Risk Indicators (KRIs) must be tied to strategic goals, demonstrating how empowering developers leads to measurable improvements.

For instance, if your strategy is to empower developers, demonstrate how this approach reduces recidivism rates (the frequency of reintroducing the same vulnerabilities) or accelerates remediation times. Leadership needs to understand the strategy behind these metrics to support the resources and initiatives necessary for success.

A New Approach to Security

The journey from technical debt to empowerment is about building trust, fostering collaboration, and aligning security goals with business objectives. By shifting the narrative from vulnerabilities to empowerment, security teams can work alongside developers as partners, not adversaries. It's time to change the conversation and embrace a culture of security that prioritizes people and relationships. It is a significant upfront investment; however, as you empower the development teams to achieve higher maturity and gain more secure development knowledge, they will need less of your attention. In fact, they might even turn the tables and teach us things we never considered!