Published on
It’s indisputable: Secure Coding Training is effective in reducing vulnerabilities in code. That’s why more and more companies are turning to this training to help speed up software deployment and prevent vulnerabilities. However, training can only be effective if the trainees actually take and complete the training, and this is just as much the case for Secure Coding Training as any other type. All the potential benefits of training become diminished if no one wants to complete it — or even start it, as is sometimes the case if accessing the training portal is a struggle.
Security team leaders have told us that a successful roll-out of Secure Coding Training software reflects positively on the team overseeing the operation, and one of the main metrics by which they're measured is completion rate. So how do you get developers to not only log in, but take and complete their training, which ultimately helps reduce vulnerabilities in your code?
The insights we’ve gained from working with hundreds of organizations and tens of thousands of developers can be distilled into the following list of approaches:
- Accountability
- Offensive Approach
- Hands-on
- Incentives
Accountability
Some organizations use accountability as an enforcement method to ensure that developers take the training. One example is to not allow developers to check in code unless they have completed the training. Many security organizations are hesitant to go down this route because they don’t want to be responsible for delaying product development. However, we’ve observed that the organizations that have buy-in from engineering for this have seen 100% completion rates. For those wary of this heavy handed approach, a milder accountability measure like issuing a reminder when checking in code that the developer hasn’t taken the training helps improve completion rates. Clearly communicating with a developer that they are working on code in production while not fully trained in security can motivate them to complete the training.
Offensive Approach
The offensive training approach focuses on adopting the mindset of attackers, and becoming knowledgeable about their methods. Offensive training offers conceptual knowledge — it is the ‘why’ of vulnerabilities — so that students grasp the underlying principles that cause the vulnerabilities. In developing these skills, developers learn to anticipate how their code could be at risk as they’re writing it, and figure out ways to write more secure code. An offensive approach to security is not only more effective than a defensive approach, but it is more engaging. An offensive approach challenges developers with new skills and helps tap into their problem solving skills. Most developers (and many people in general) think it is fun to learn how to hack, so engaging developers in training with hacking will help increase completion rates. Many developers will get wrapped up in the training and some will even find themselves doing lessons they haven’t yet been assigned. Some organizations have even requested us to lock lessons so that developers wouldn’t get ahead of the training schedule — a good problem to have.
Hands-on
Passive training will not engage developers. Video, slide or multiple choice training are all examples of passive methods which developers will grudgingly endure if required, but they’re not likely to actually learn much from them in the process. Developers learn best by doing, so giving them both offensive and defensive hands-on training where they actually have to write code is very engaging. One company we worked with came to us after they had used slide-based training. They said that the developers would just click through as quickly as possible to get through it. When they looked at the training report, developers had finished in seconds — a clear indicator that this passive approach was not engaging or desireable to the developers.
Incentives
Never underestimate the power of swag as a motivational tool. One organization we worked with gave out backpacks bearing their logo for completing the curriculum. Even though the organization made training voluntary, their completion rates were off the charts - almost hitting the magical 100% mark. There was no struggle, just developers wanting to participate and receive the backpack. We have also seen companies use special shirts, coins, even gift cards to get developers to complete training. This works! Some people think that you shouldn’t have to provide any incentive — that developers should just want to do it and increase their skills. In an ideal world, that would be the case, but in reality developers have a lot of competing priorities, and security training may not make it into the running without some extra incentivisation. If you think of the swag purchase as part of the investment into improving the security of your product, then it can be well worth the return.
Conclusion:
Every organization enters the training arena from a different developmental stage when it comes to building a security culture. For organizations that are just starting to build a security culture or have tried and failed in the past, it can be especially daunting to attempt this challenge — both from a managerial perspective and from the perspective of developers who may worry about any additional “work” that is “forced” upon their already busy schedules.
But requiring training should be no different than requiring scanning software with a SAST tool, or even conducting software testing. Using incentives, accountability, an offensive approach, and hands-on training will help ensure everyone gets through the training, resulting in more secure software.
