Motivating developers to write secure code
As we spoke about previously we continue to see the exploitation of common software vulnerabilities leading to high impact outcomes. This is despite the availability of security tools and processes (think Security Development Lifecycles) that are designed to help improve the security of software development. This leads us to question why these tools are not having the desired impact.
Back in 2017 we trailed an NCSC-sponsored research project looking into how software developers could be motivated and enabled to adopt and integrate secure coding practices. Run by our Research Institute, RISCS, the project's full title is: ‘Motivating Jenny to write secure software: community and culture of coding’.
This project took a different approach to the secure development problem, flipping it to look at it through the eyes of the developer, building on learnings from the social sciences. Engaging with developers through face-to-face meet ups, online forums and questionnaires, the project looked into understanding the realities of everyday development practice.
It has now borne fruit in the form of a toolkit, designed to help organisations of all sizes change the conversation about security within and around development teams. This blog post will outline the major findings of the research, which through engagement with developers, has produced a toolkit to help developers consider security during their daily jobs.
Motivation not lacking
Whilst 'Motivating Jenny' initially focused on finding ways to encourage non-security expert developers to write more secure code, it quickly became clear that motivation was not the central issue.
The core problem was how to create conditions under which developers can appropriately apply the security knowledge they have gained through other educational and awareness activities.
In other words, helping developers to spot security-relevant decisions, so they can develop a sense of when security is needed and why.
Recognising a range of responses
Whilst developers may encounter security decisions during their work, it is not their main focus. Variation in experiences of working with security mean different developers will respond differently when faced with a security decision. This research, through existing literature and developer engagements identified five common developer responses to security tasks:
- Worry: Engaged, but not particularly active. A person who is worried may be aware that more could be done around security, or worried about the way things are being done, but doesn't necessarily have the ability (or perceive an ability) to act.
- Follow: Not particularly engaged, this person follows signs in code about security, or prompts from others, or follows the policies set forth by the company. Many developers give this response, but care should be taken not to conflate this response with a lack of skill or experience.
- Explore: Engaged, possibly active. This response is marked in people who demonstrate a high degree of interest in security. This person could have an active role in security activity at the company, or advocate for activity.
- Float: This person seems to know something about a range of technical topics, including security. This person would not describe themselves as a security specialist, but can often be seen stepping in to help others solve problems that turn out to have a security aspect.
- Engineer: Engaged, active and very capable. This response may be seen in a person who is a specialist or near specialist in some aspect of security.
These responses vary according to the task, the surrounding security culture(s) and the individual’s experience.
"So what?" you say, but through identifying these responses managers gain richer information of the issues that developers are experiencing when they engage with security. This ground truth is a powerful way of intervening effectively in the workplace to help developers with security, whilst enabling them to get their jobs done.
Changing the conversation around security
The Motivating Jenny materials can help development teams to complement technical training by focusing on the social aspects of security.
The social science based research shows that developers approach security through social connections, undertaking technical challenges alongside team members, keeping up with new technologies online, and building relationships that provide assurance on good practices that make things more secure within teams, companies and client sites.
Building on this, the materials are designed to promote informal engagement among developers, and to change the conversation around security within the workplace.
This toolkit will help cultivate a working environment that supports a mix of responses to security: an environment in which developers can speak up, learn, and form connections with one another, so they are better equipped to spot security tasks that are relevant to their work, and in turn produce more secure products.
What makes up the toolkit?
The project has developed 4 tools, designed to help software developers get comfortable with cyber security:
- Security in the World: uses structured discussion of real-world security incidents, seen from two different points of view to promote discussion about the impact of security issues on developers and teams.
- Security in the Community: provides pointers on how to use comment streams on developer forums, such as StackOverflow and Reddit to learn about security issues, as they intersect with common development tasks.
- Security and Me: is a self-assessment questionnaire to prompt reflection about individual attitudes to work and security.
- Security Between Us: uses focussed discussions on active security issues between team members and between teams.
These 4 practitioner packs can be adopted and adapted for use in different contexts. You can download them from the Motivating Jenny website.
Useful links:
NCSC Secure development guidance
David K
Sociotechnical Security Researcher
Share and print this article
Written by
