There will always be a natural tension between cybersecurity teams and developers. After all, it’s the developer’s role to “develop.” They want and are paid to create and ship new applications and features that help move the organization forward. It’s the role of security, however, to make sure bad things don’t happen when new software is deployed, such as suffering from a data breach or the loss of availability of business services due to vulnerable software. 

While this dynamic does create a natural strain between the two roles, it’s my experience that it doesn’t have to be this way. Not if the proper steps are taken to increase the understanding between the two groups. 

Unfortunately, many organizations don’t take the proper steps, leading to the development team viewing security teams as a “roadblock” — a hurdle to overcome. Likewise, the security team’s animosity toward development teams grows as they view developers as not “taking security seriously enough.”

There’s been a lot written about how to improve the relationship between developers and security teams. And the last decade has seen the rapid expansion of DevOps practices meant to alleviate this tension. There’s been some success, but not enough, in my view. That’s why I’ve decided to share what I’ve learned from managing the application security team at a large telecom with some success in balancing the tensions between developers and security.

All organizations are different. Some development and security teams work primarily in-house, while others work largely remotely, and others are still a mix of both. Some teams have very experienced application security experts, and others don’t. The team I worked on mainly was on-site. And what worked for us may not work for everyone. Still, I believe those who incorporate these keys will improve the critical relationship they have between their security and development teams.

Key Number One: Emphasize training.

Organizations should provide application security training to new developers, led by the AppSec team with someone with enough development experience that developers feel they would respect. Those AppSec experts with development experience understand the issues and frustration that developers face when security teams communicate in less-than-optimal ways.

This also broadly applies to the AppSec team. When you have an AppSec team built just by security people who have never worked in development, that situation will likely cause friction between the two groups because they will probably always speak two languages. And neither group understands the problems and challenges the other team faces. When you have an AppSec team that includes prior developers, you will see a much different relationship between the teams.

Key Number Two: In AppSec training, use real-world examples that the development and security teams found internally.

In all AppSec training, the trainers will discuss how vulnerabilities are introduced into code, such as injection flaws, cross-site scripting, and poor access controls. And they’ll describe what these vulnerabilities mean to the application and data security. While this presentation may be accurate, it’s also very bland. 

To spice things up and gain attention, we found success by adding application vulnerabilities that the security team found while conducting security checks in-house. This is not to make the AppSec training personal. Individual developers absolutely shouldn’t be called out. 

It’s about learning about these issues together. It’s about showing that developers are focused on the business logic and the workings of the application they are building and not security. And sometimes, security is at the back of their minds, and that’s understandable. But you’ll capture their attention and interest by taking a few examples of common vulnerabilities found in-house that impact the organization’s security. 

Key Number Three: Remove the stigma of vulnerability discovery.

We presented a slide at the beginning of our presentation that helped remove the stigma of having security vulnerabilities in one’s code. I won’t reveal the name behind the announcement, but the slide involved a well-known security professional. He builds security software that is released as open source. He had a vulnerability in software that he created that was released as open source. And it was a very critical vulnerability. 

If this person can release software with critical vulnerabilities, any developer can make the same mistakes. We presented that slide to show them that having security defects in code is normal, even for someone very experienced in application security. The important thing is to find and remove them. 

Key Number Four: Teach the actual impact of vulnerabilities.

We also didn’t just present vulnerabilities that we uncovered in-house. We also exploited vulnerabilities. We should show the developers how the vulnerability can be exploited and what an attacker can do with that vulnerability.

In one of the initial training sessions, a developer commented on cross-site scripting and made assertions that such vulnerabilities can’t be that harmful. We showed them what an attacker could do with a cross-site scripting attack, such as victim impersonation, accessing sensitive data, session hijacking, keylogging, malware dissemination, and more. 

This was very eye-opening. And in fact, I think this is a problem with AppSec. When developers don’t understand the impact of vulnerabilities, they are not motivated to fix or avoid having them in their applications. It’s human nature to ignore risks when they don’t understand their impact. That’s why demonstrating the actual risk can have so much impact. Adding this to our training helped us drastically improve our relationship with developers. 

Key Number Five: Security teams need to understand what’s reasonable.

I’ve found that friction between these two teams is often caused by the security team asking for tasks that are unreasonable to be completed. During training, it’s essential to teach the development team how to work best with the security team, that’s for sure. But it’s just as crucial that the security team ensure their requests are reasonable. 

Sometimes, there are unreasonable requests because the security team asks for things that aren’t actual issues to be fixed. This happens when they run an application vulnerability scanner, and the scanner reports a vulnerability that doesn’t exist or expose an actual risk. The security team blindly passed that on to developers to remedy. When you do this often, the developers will get frustrated and ignore you. 

Also, security teams have to be reasonable with their expectations, such as providing adequate time to address vulnerabilities and more time to fix complex vulnerabilities. 

Key Number Six: Use Accurate tools that empower developers.

Making sure to pick accurate assessment tools is essential because such tools provide clear explanations of identified issues, assign proper severity levels, and offer guidance on resolving the vulnerabilities. 

This will help developers to understand how to address the issues at hand. And providing tools that are designed for developers to use is even better, as this will enable developers to work independently. 

While the tensions between security and development teams will always exist to some degree, and organizations will have to make some continuous efforts to mitigate these tensions, we found that by taking a few simple steps that improved understanding and empathy among these teams goes a long way to improving these relationships.