Continuous Reminder

Incentivising developers to know the importance of security is all very well, but faced with normal life people forget quite quickly. So make sure you have a trickle of regular events and nudges to remind the team.

Pointing hand

While your initial Incentivisation Event  may be effective, its impact is relatively short-term. After a few weeks or months we usually find that the drive of the development team to do security tends to be lost. 


To counter this, it’s important to keep reminding the team of the need for security. Typically this needs to be at least every month. You can think of the technique as kinds of ‘nudge’: small reminders of the importance of security issues. 


A particularly good nudge is positive feedback built into the development process. Look for a way to give developers small encouragements for their successes related to security, even quite small ones.


The other thing I have to mention is the feedback loop. A pen test report or even just a static code analysis coming back and saying you are doing well – having a desk report or the executive summary that says “wow that is a really secure application, well done!” (Security trainer & consultant)


You could consider a monthly security competition, defining teams and awarding points based on the security success of each.


We tally the results, and there is a league table, and the team at the top get a prize and a little trophy, and we have these 'town halls' and all that.  (Security expert, Internet infrastructure provider)


This kind of positive feedback may even be built into automated tools. For example Detectify, an online web security review tool, produces encouraging feedback to its users in the manner of fitness apps, before making suggestions for improvement. 


Now you have 8 out of 10. Nice work! (Detectify)


We strongly recommend also using a 'nudge’ approach with your project stakeholders. Use incidents in the news to remind product management and senior management of the importance of security.


Never waste a public disaster. If it is in the news, everyone here has read about it. Like Sony: we went straight to our VPs and said “right, what if that was [us]? What would you do, how would we cope, how would we react, what would it do to our share price?” (Security team lead, Operating system supplier)

On-the-job Training

Consider arranging training sessions. A commercial training course might be useful. But even more helpful are regular events of different kinds. They too can be ‘nudges’, reminding the team of the importance of software security.


Some teams have found ‘brown bag’ sessions very helpful: informal presentations and discussions involving the whole team. Because they are valuable as nudges, it is more important that they happen than that they are good! A presentation that leads to an animated discussion between team members is excellent.


Good people to lead them might be your security champion, or an external security expert. Typical topics might be sharing recent security experience from one’s own and related projects; or discussing different kinds of security issues


[Our security specialist] will take the most interesting or most relevant findings for the team out, and those go into a slide deck that we keep, and that deck is used as part of a show and tell. That happens… a few times a year. (CEO, outsourced secure web developer)


Another possibility is for developers to work together through some of the ‘ethical hacking’ training materials to learn how an attacker might work. [XXX Ethical hacking courses]. 


I think training is obviously very effective, and we sometimes do specialised training. ... So we had pen testers coming in, and I have got it so that we can now do it ourselves, where we have got a VMWare image with all the hacking tools on it, and vulnerable webpages, so they can play and see how easy it is – and what issues they need to look for. (Security expert, Web infrastructure provider) 


There is a variety of courses available; however almost all concentrate on purely technical attacks, so we recommend having other forms of training as well. 


Another possibility is for the whole team to work through a checklist of types of security defect, such as the OWASP Top Ten, concentrating on a different one for each month or project release. 


These are all good - what is important is the reminder, not exactly what it is. Do any of these, or anything else the team thinks up, so long as it has a regular reminder: you need software security!