Many working in the information security field have seen companies make an increasing commitment to software security. The job offerings associated with these efforts suggest that organizations are primarily focused on testing. Training providers have mirrored this trend by expanding courses that focus on penetration testing and offensive security. Even the public sector has gotten on board by introducing revisions to the FISMA guidelines that call for “vulnerability assessments and penetration tests commensurate with the risk posed to agency information systems”.  But testing, from the software development perspective, is one of the last steps in the development process, aimed at validating requirements and exposing edge cases. A successful application security program relies on a more well-rounded approach to creating secure software.
This is not being said for the first time. Collaborative groups like BITS and SAFECode have recognized the need for integrating with the development process as early as possible.   But as security activities move further upstream during development, the availability (or popularity) of practical information starts to decrease. And for every vendor tool designed to create security requirements for a development effort, there are ten or more designed to attack it.
Secure development relies on a number of early activities – risk assessments, threat modeling, code review – but developer training should be the earliest, and the foundation of an improved application security program. For anyone who has clicked through an annual security brief in five minutes, this may come as a surprise. That is why it is important to carefully select the kind of training that is delivered to developers.
Secure code training should show developers the most prevalent vulnerabilities and the ways that they end up in applications. The OWASP Top Ten Vulnerabilities are consistently used as the road map for this content. Courses should also cover the early security activities that are effective during application development. Training should ensure that an activity like threat modeling is implemented correctly.
Security training should be delivered to everyone involved in application development. Software engineers are the obvious audience, but some discovery is necessary to ensure there is coverage for other roles. Not every responsibility may be captured in the policies that guide an organization’s development process. One effective approach is to conduct meetings with a sampling of people actually doing the legwork. You may find that non-technical Business Analysts are being asked to create security requirements, or that Quality Analysts aren’t consistently validating them. This interaction is a valuable source of information during a gap analysis.
Training should be targeted and specific. It may be necessary to survey development teams before an organization can be certain what languages and platforms are being used. Developers should learn to recognize vulnerable code in the language of their choice.
Proficiency testing isn’t good enough – behavior change requires practice. Developers learning to prevent injection need to actually construct parameterized queries during the course of their training. This can be achieved with computer-based training but is better accomplished through . . .
. . . instructor involvement. MIT’s Training Delivery Guide states the obvious by calling “classroom training with instructor” the best delivery method for practical exercises.  On-site training provides the opportunity for guidance and hands-on exercises in a laboratory environment. It also demonstrates managerial buy-in to developers. An organization that devotes time to providing classroom training shows developers their commitment to security. This addresses the leading concern during an effort to improve application security – that developers will be asked to do more in less time.
In addition, the presentation of computer-based training can be just as important as the content. Voice actors need to have a technical background (LDAP is pronounced el-dap). Secure code training needs to set itself apart from the annual security slide show on phishing. It is part of (or should be part of) the organization’s role-based security training, not the basic awareness training. It should also live up to its own standards. If the breadcrumb links don’t work properly to navigate between courses, how can web developers be expected to take the training seriously?
Lastly there is the opportunity to provide incentive. Developers who pursue secure coding certifications may become eligible to work on more challenging and competitive projects. NIST points out that good training should contribute to career progression, and that organizations “. . . offer pay raises and bonuses to retain users with certifications.”   Voluntary training activities like security conferences and events might also contribute to an employee’s professional development goals.
Going forward – if an organization has a commitment to software security, they will increasingly want to improve their development efforts from the ground up. The cost savings and effectiveness of this approach are undisputed. Training is the key element to affecting a behavior change during development and should be at the core of new security activities. This gives security analysts the chance to create original programs with the support of high-level stakeholders.
As you author a program, you may find that all the annual security briefs have given you an important piece of knowledge: you now know what bad training looks like. Armed with that knowledge, use this opportunity to give a program that you’re proud of to developers.
 Federal Information Security Amendments Act of 2013 H.R. 1164 – Page 5
 BITS Software Assurance Framework
 Fundamental Practices for Secure Software Development
 MIT Training and Development Guide – Page 1
 NIST SP 800-16: Information Technology Security Training Requirements – Page 44
 NIST SP 800-50: Building an Information Technology Security Awareness and Training Program – Page 10