Depending on your culture, this may incentivize a decent percentage of your target population. Gamification is pretty popular today and can get competitive juices flowing. The training you selected may or may not lend itself to gamification. If it’s designed with gamification in mind, then it’s easier to pursue this strategy. There are multiple levels of gamification that can be sought. Typically, you would start with primary challenges, badging, and scores. Going deeper would involve more integration with challenges, social network sharing (internal or external), personalization, and individual leaderboards.
Dashboards are typically built to align with organizational structures. They roll up to a logical level of management, usually the developer’s manager and the next level or two depending on the size of the organization. We have found that it’s beneficial to group students by three or four progress levels depending on the type of training course they are taking. For example, you could use ranges like 0-33%, 34-66%, 67-99%, and 100% completed or more general terms like Registered, Coding, and Completed. If managed well, these dashboards can help drive a little friendly competition between members of management to help encourage prioritization of training. Stimulating discussions about the training between developers and their management can also improve the understanding and support for secure development practices within the organization.
Performance Requirements are the more traditional way of handling activities that are considered mandatory and not something people would do voluntarily. It’s directly tying a reward or punishment to their efforts. Sometimes this is coupled with the team/leader dashboards, and sometimes it’s deemed enough on its own. This strategy generally ensures that targeted individuals will complete the training. On the other hand, if you pursue this strategy without management support and encouragement outside of “do it or else,” information retention and overall feedback on the training will likely be tainted heavily in the negative regardless of the quality of the courses.
Also, with any secure development training program, I highly recommend you consider how to measure the benefits or improvement as a result of the training in your code base. Traditional measurements are pre-test/post-test and knowledge-based multiple-choice quizzes. While these can be used to test short term knowledge retention of the topics, it doesn’t necessarily correlate to actual security improvements in your organization’s code base. Measuring real improvement to your codebase is not an activity to figure out after you have sent everyone through training, this is something that you need to figure out how to baseline before you start a training program if at all possible.
Look for measurements like the number of vulnerabilities per build or release or similar metrics that are pre-release and post-release. Find or build a consistent, repeatable process, that enables you to gather solid metrics for a baseline. Then, as teams complete the training, monitor the results for statistically significant changes in the numbers. It might take a little while for them to show up, depending on the workload of the team and how they are coding. It could take several months or a year. While that may seem like a long time, it’s important to remember that software security is a long game, there are some quick wins you can realize, but the most beneficial gains are long-running cultural changes that may even stretch generationally.
nVisium provides both Instructor-Led training and a unique form of online developer training that combines the hands-on labs typically only found in Instructor-Led courses with the convenience of online training. You can learn more about our training offerings at https://nvisium.com/security-training