6 Developer Personas Every Security Practitioner Needs to Understand

When it comes to engaging developers for a successful application security program, it is helpful to understand the types of developers you are working with. While of course each developer is a unique individual, there are some common personas I have come across in my work with development teams. In fact, as a developer in prior jobs, I have embodied some of these traits myself. Let’s dive in.

The Competitor

This is a developer who feels they know more and do more than their peers, and they want everybody to know that this is the case. These individuals want to be acknowledged as a top contributor and expert, and they treat their work as an opportunity to demonstrate their capabilities. 

I remember one team ran a scan using an open-source security tool. The scan uncovered around 500 vulnerabilities. The competitive developer took it upon themself to go off, work extra hours and weekends, and single handedly resolve each vulnerability. 

To engage the competitor, you can try to rollout competitions, for example to see how many flaws each team member can identify or remediate in a given window of time. 

The “Lazy” Developer

While I understand the word “lazy” has a negative connotation, I find this persona to be a valuable team member. This can be a person who says that because they are lazy, they spent a weekend writing a new script that automated a recurring task. These developers are constantly looking for opportunities to eliminate repetitive tasks. If they do something two or three times, they will start looking for a better way, seeking to automate whenever and wherever possible. These developers fear and loathe rework. They will seek out articles and resources, research what others are doing, and try to weed out redundant or wasted effort. 

The more you can support the lazy developer in their quest for efficiency, the better. Arm them with resources that enable more efficient implementation of security measures. 

The Creator

Every day, this developer thrives on being able to create something new that never existed before the day they wrote it into existence. These individuals gain gratification from building something and being able to hand their work over. These developers tend to dislike technical debt. 

Business owners and development leaders are constantly pushing teams to deliver new functionality faster. The creator will thrive by generating the code required, but they will also tend to be torn if they feel that, in their rush to meet deadlines, they may have overlooked some issues. Given this, it can be extremely helpful to arm these developers with tools and resources that help boost productivity, while strengthening quality assurance. Provide tools that help creators do scans quickly and verify whether any flaws were introduced. 

The Oracle

The oracle is a developer who will read source code and feel they will learn exactly how the system works. Based on this reading, they may come away feeling certain they know exactly how a certain app will behave. However, this certainty is not always well founded. Things change in a code base and even if they understand the details today, they might not understand intricacies of a new branch started tomorrow. Their fear is that they will have holes in their knowledge of the entire system. In working with these developers, it can be beneficial to help illustrate where problematic areas may be, and to provide constructive input on seeking out and addressing potential issues. 

The Skeptic

This developer will tend to look at vendors’ solutions, and indeed the work of other teams, with skepticism. They will inherently doubt the efficacy and quality of others’ code, with confidence they can build it better themselves. To support this perspective, they will be ready to pounce upon any flaw, and use that as justification to write the entire application security solution or program off. 

In working with a skeptic, it can be helpful to provide objective proof points and sources of validation. When it comes to introducing a vendor solution, it is important to underscore the vendors’ track record, how long a solution has been in production, and how many experts it took to guide development and refinement. In this way, you can underscore the impracticality of many in-house projects. The skeptic will soon realize that they were tasked with other objectives and return to them.

The Captain

The captain elevates team performance by placing the success of the team at or above the level of their own success. Often, they are motivated by a purpose higher than their own individual code – whether that be seeing and contributing to colleagues’ growth, working on projects that align with their intrinsic values, or contributing to organizational success. 

Captains are key to team culture. You should seek to align with and recruit these developers for the cause of security. If you can build trust with these individuals – and communicate how security contributes to the success and well-being of the team – they can become the security champions in your organization who help carry the security message and motivate colleagues.

Approach Developers Differently & Creatively

Developers are a diverse bunch, and it’s important to understand what drives these valuable members of your team if you want your application security program to succeed. By understanding these six developer personas, you’re well on your way to getting buy-in and participation from developers. Keep in mind not every developer will fit neatly into one of these categories, so don’t hesitate to get creative and tailor your approach accordingly.

A great way to start engaging all these personas is through secure code training. Click here to sign up for a free trial of Security Labs, our experiential and exclusive developer education solution.