How to Engage Developers to Build a Successful Application Security Program

If you’re helping shape application security in an organization, whether as an external security consultant or vendor, or as part of an internal security team, it is critical to work effectively with developers.

While a lot of individuals have an interest and stake in security, and many have a significant role to play, developers who write code and fix flaws determine whether application security initiatives succeed or fail. Fundamentally, developers are the ones who operationalize application security. The sooner and more effectively they address security issues, the more secure applications will be. 

The problem is that security is not developers’ only area of responsibility. Developers have a lot of competing demands and are typically evaluated and incentivized based on speed of delivery and productivity—rather than security. 

For those focused on security, it can often be a battle to engage effectively with developers and get the buy in and participation required. If you only engage with top-level development leadership, or you try to force an approach or solution on a team, you may be derailed by overt or covert resistance which can lead to snags and diminished returns. 

I have been fortunate enough to work in development and to work with developers extensively in recent years, and there are some key approaches we have employed that have proven useful. The following sections offer some high-level guidelines for developer engagement, and you can find different developer personas we have seen and some specific ways to engage with those personas in my blog on the 6 Developer Personas Every Security Practitioner Needs to Understand.

Guidelines for Developer Engagement

Show Interest and Empathy

It is important to start by getting to know some specific developers. Show interest in the problems they are trying to solve and what they are building. Take time to get to know what their typical day looks like and areas they are struggling with. All this is key to establishing a rapport and foundation for collaboration. Further, by taking time to understand the applications they are building, you can add more value to the conversation and get more insights into potential threats and threat actors.

As part of this, it is important to understand where different teams and developers operate. This area of responsibility will matter as it will shape their role in security and the specific portions of threat models they will be tasked with addressing, and this should guide conversations. For example, a front-end developer may not be interested in discussing the security of the backend portion of their organization’s environment. 

Understand Developer Motivators

On any given day, for any given developer, the top motivators can vary. The following are motivators that typically drive developer behavior:

• Contribution. Like most people, developers are happier when their work leads directly to positive change, and when they can see the impact of their effort in the larger team and organization.

• Problem solving. If there is one thing all developers share, it is that they fundamentally want to solve interesting problems. They enjoy being presented with difficult challenges and devising creative solutions. 
• Pride in work. Teams want to take pride not only in their work but in the applications they are contributing to. They want to see these applications succeed and receive positive feedback and recognition. 
• Responding to business leaders’ directives. Sometimes, the objectives of leaders will be at odds with developers. While it will be common for a developer to want to take the time to strive for perfection, it will be the business owners who will set directions for getting minimum viable products out to market within specific deadlines. Understandably, developers are motivated by these directives. 
• System stability and firefighting. Tackling urgent, critical issues can be a motivator for some developers. There can be a rush associated with responding when an emergency arises and being a heroic figure that puts out the metaphorical, “system fire.” (For anyone who has read the Phoenix Project, Brent Geller, Lead Engineer for Parts Unlimited, is a vivid illustration of this.) There can be an element of job security as well when teams are working with systems that are prone to issues. 
• Expertise and deep knowledge of complex systems. Application code is invariably complex and developed by several teams and developers. Developers can feel a sense of gratification from being able to understand these complex assets and really know what makes them work the way they do. This can also include creating and managing the interrelationships and integrations with disparate systems and services. These connections can be complex and challenging and can also enable significant advances in value.

• Relationships with other developers. Developers will be motivated by accountability to other team members. No one wants to feel like they are the proverbial “weak link” who is letting their teammates down, making their jobs more difficult, or keeping them from meeting team goals. 
• Learning and career advancement. Many developers thrive on being able to learn. Developers want to build their knowledge so they can be more valuable teammates and so they can advance their careers. 

Align with Motivators

With an understanding of the aspects that motivate developers, you can then start to align conversations with those aspects. If the top motivator is meeting a business leader’s ambitious new deadline, start to focus on those aspects that can support them.

Collaborate and Establish Trust

It is important for security professionals to truly partner with developers. This means engaging, soliciting feedback, and responding to that feedback. Over time, teams can establish trust, which is a vital piece of cultivating the required changes in behavior and approach. 

Be Positive

As an application security consultant or leader, it is important to try to stay positive, instructive, and supportive. This is particularly important when it comes to discussing vulnerabilities and flaws. While sharing this type of intelligence is vital, the focus should be on identifying areas of improvement rather than shaming or calling out a particular developer or team. 

Articulate the Value of Security

While security can often be discussed as a proverbial “stick,” with all manner of negative repercussions for gaps and failures, the reality is that strengthened application security can deliver a lot of positives. Try to describe the positive outcomes that will result from more secure development. Following are a few key outcomes: 

• Enhanced business results. If you can tie security efforts to how developers can help support business goals, such as cost savings or increased revenues, it can be very motivating for developers. 
• Learning opportunities. Developers in general enjoy being able to acquire knowledge, and if they can learn about security best practices and acquire skills, they will understand it can help them be more productive and boost their careers.
• Being more proactive. By shifting application security efforts left, or earlier in the development lifecycle, teams can realize many benefits. For example, fixing security issues late can often result in those drop-everything, all-hands-on-deck efforts required to handle remediation. This context switching is fundamentally counterproductive. Beyond whatever time is spent fixing the issue, it typically takes another half hour at least for a developer to get back to where they were if there had not been the interruption. Fundamentally, all this time is time that cannot be spent on revenue-generating development. 

Gain and Document Buy In

Do testing and proof of concepts, gain developer buy in, and document that buy in for other developers and stakeholders. This can be invaluable in avoiding opposition and potential obstacles. As part of this, you can also highlight a particular team’s or developer’s work, which can serve to build awareness of your security initiatives and gain positive recognition for developers, which can further engender trust and collaboration.

Make Security Requirements Part of Sprints

Look to create specific security requirements and gates as a part of development teams’ sprints. While this can be perceived as adding extra work or overhead, the reality is that this makes it easier for developers. This gives them concrete justifications for ensuring issues are addressed up front and pushing schedules back when vulnerabilities have not been addressed. As noted earlier, this is far more efficient and far less disruptive than catching issues later. 

Optimize Your AppSec Program With a Security Platform

While strengthening application security in an enterprise truly takes a village, ultimately the results realized will rely heavily on developers. It is vital to engage with developers early and often to establish an application security program built for the long haul. 

There is a significant difference between implementing an application security tool and establishing an effective application security program. With our solutions and services, we can help work with your development teams, as well as security and business leadership, to build an optimized security program in your organization. To see how our platform can work for you, book a personalized demo here.