The February 2018 workshop on developer-centred security (DCS) had four parts. After an introduction and background summary by NCSC’s engineering processes and assurance lead Helen L (below), a Developer’s Den set up a feedback loop between researchers and practitioners where comments from researchers and practitioners were sought on a series of short pitches describing new tools and techniques. Next, a reverse panel session asked senior representatives from government and industry to pose questions and articulate challenges for the RISCS DCS community to consider. Finally, in a series of lightning talks, researchers from the £1.5 million DCS portfolio that sits under RISCS presented updates on their work in progress.

The RISCS secure development subcommunity was created in 2017 to research ways to support developers write more secure code. To date, developers have been seen as a ‘weak link’ and imposing more and more security processes has not been effective. This research seeks to understand more deeply the behaviours and motivations of developers, and how this affects the security aspects of the code they write. This will help us to understand how they can be better supported. Once they have established a better understanding of the landscape, their goal is to use the results of this first phase of research to improve the products that support developers on offer in the marketplace, and use those results to create a positive feedback loop to inform further research and products in development. NCSC has already published secure development guidance with this work in mind. With advice from the developer community, NCSC intends to issue further guidance for those involved in supporting developers.

For the workshop held on February 8, 2018, Helen L was seeking advice, guidance, and input from those supporting developers working in various sectors: startups, government, industry. Helen L described secure code development as a “leaky pipe”:

The leaky pipe of secure software development

Helen L’s leaky pipe of secure software development

As the image shows, there are many opportunities for stopping those leaks:

  • education to support developers to learn about security;
  • organisational culture, which is important to how developers feel about security and whether they are incentivised to implement it;
  • motivation;
  • behavior and habits;
  • support for developers.

Following on from the 2016 developers workshop, RISCS has projects addressing some of these aspects. Why Johnny Doesn’t Write Secure Code looks at how and why security vulnerabilities arise from developers’ mistakes and asks how to mitigate them. Motivating Jenny to Write Secure Software studies what motivates software developers to do secure coding, and how to improve their motivation, tools, and culture. For a small grant project in 2017 Charles Weir investigated intervention strategies. All of these are intended to take a new, more productive approach by identifying potential interventions and understand the daily pressures on developers and how they understand security, given that they are not experts in this area.

Helen L believes it’s important to take support to the developers rather than waiting for them to find published advice and guidance. The goal here, therefore, is to facilitate a feedback loop between research and industry, so the two can move forward collaboratively.

Wendy M. Grossman

Freelance writer specializing in computers, freedom, and privacy. For RISCS, I write blog posts and meeting and talk summaries


Developer-centred security: lightning talks | RISCS · 11/04/2018 at 08:38

[…] to their work, followed by a general discussion. The other sessions from this workshop are: introduction and summary, developer’s den, and reverse panel […]

Developer-centred security: reverse panel | RISCS · 11/04/2018 at 08:38

[…] panellists challenged the audience with provocations. The other sessions from this workshop are: introduction and summary, developer’s den, and lightning […]

Comments are closed.