How To Create a Successful Secure Coding Training Plan

Originally posted: https://blog.hackedu.com/how-to-create-a-successful-secure-coding-training-plan

Developing a secure coding training plan for frontend and backend developers as well as Quality Assurance (QA) engineers can be difficult. How can you develop an effective training plan that reduces vulnerabilities, doesn’t take time away from product development, and that developers will appreciate?

Based on working with hundreds of organizations and tens of thousands of developers, we have derived best practices; whether you use HackEDU, another vendor, or develop training internally.

Every company is unique, so “best practices” for one organization may not always be the best practice for another organization. So conforming to all “best practices” laid out in this article may not be possible or even ideal. Try to optimize in as many areas as possible to get the most effective secure coding training plan. If you have any questions or would like help creating a training plan, whether it is with HackEDU or not, please reach out to trainingplans@hackedu.io.

Training Content

Hands-on training, requiring developers to actually code, is highly recommended. This ensures that developers are practicing what they are learning and getting experience in the outcome; secure coding. Multiple-choice lessons, videos, and slides are not as effective as real hands-on coding.

Most companies that have tried videos or slides for developer training have come to the conclusion that it is not effective because it does not engage developers, and developers do not have the opportunity to practice the skills they are learning. Developers do not take the training seriously because they enjoy solving problems and writing code, not watching videos or slides on secure coding. Putting in a little more effort into hands-on training can have a tremendous impact.

Hands-on training should include practicing finding and fixing vulnerabilities in code. In addition, developers should be taught the offensive side of security. It has been shown to be more effective than defensive training alone. The offensive side of application security gives developers a deep understanding of the mechanics and fundamentals of vulnerabilities so they can think beyond just one scenario; instead being able to think through generalized attack scenarios and better defend.

Training Schedule

Training as a one-time event, rather than being consistent throughout the year, is not as effective and leads to more push back from developers. Developers do not want to be forced to take training in a short duration, such as one week or even one day. Developers have a lot of priorities so on-demand training often works better for their schedule. In addition, it makes developers feel like they have more ownership of their training, therefore less forced.

Spreading training out over an entire year also ensures that it does not take too much time away from the organization’s product roadmap. Ideally, 1–2 hours of training should be scheduled every month so that developers are not too distracted from developing, and security skills are building up over time. Sometimes there are compliance deadlines and it’s not always possible to spread training out throughout the year. If there is a compliance deadline, then the lessons required for compliance should be taken. Additional lessons, 1–2 hours every month, should be assigned to build and reinforce secure coding knowledge.

Training Topics

Developers should receive different training based on their role and their seniority. With that said all developers should go through the Open Web Application Security Project (OWASP) Top 10 vulnerabilities to gain a basic understanding of their mechanics and how to prevent them. More senior developers may be given an opportunity to test out of the basic training.

Training results should be tracked and developers who are not doing well in certain topics should be assigned additional training in those areas.

Below are role-based training recommendations.

Backend Developer

• Lessons on each of the OWASP Top 10
• Cross-Site Request Forgery
• NoSQL Injection (*if applicable*)
• JSON Web Token (JWT) Authentication Security (*if applicable*)
• Cross-Site Scripting (XSS) Lesson 2
• Real-World Lessons (e.g. Capital One Breach, Drupalgeddon2 Remote Code Execution, Remote Code Execution (gm convert), SQL Injection with SQLMap, and Blind XXE)

Frontend Developer

• Lessons on each of the OWASP Top 10
• Cross-Site Request Forgery
• JSON Web Token (JWT) Authentication Security (*if applicable*)
• Cross-Site Scripting (XSS) Advanced lesson
• Real-World Lessons (e.g. Capital One Breach, MySpace “Samy” Worm, XSS in Third-Party Integration, ClickJacking, Blind XXE)

Quality Assurance (QA) Engineer

It is important for QAs to have a hands-on understanding of software vulnerabilities. Some QAs are not as strong with coding, so allowing them to opt-out of taking the coding part could be beneficial. In addition, having challenges or labs they can go through to practice finding vulnerabilities and using a web proxy, is important.

• Lessons on each of the OWASP Top 10
• Cross-Site Request Forgery
• NoSQL Injection (*if applicable*)
• JSON Web Token (JWT) Authentication Security (*if applicable*)
• Cross-Site Scripting (XSS) Lesson 2
• Real-World Lessons (e.g. Capital One Breach, Apache Struts 2, Drupalgeddon2 Remote Code Execution, Remote Code Execution (gm convert), SQL Injection with SQLMap, XSS in Third-Party Integration, and Blind XXE)
• Memory Management Lessons (Stack Overflow, Off-By-One, Heap Overflow, Format String)
• Offensive Based Challenges (e.g. CTF style “testing” challenges, such as /etc/passed File, Indicating Hints, Bank Transfer, etc.)

Senior Developer

Senior developers should focus on lessons that go through real-world examples. Besides going through standard lessons based on their role, it is important to go deeper. It is one thing to make up an application with a vulnerability, it is another to see how a vulnerability ended up in an organization’s production code. Real-world examples tend to be more nuanced and can sometimes rely on several vulnerabilities for the application to be exploitable. It is highly recommended that senior developers are exposed to these real-world examples and have lessons that walk through how to defend in these scenarios.

If you have any questions or would like help creating a training plan, whether it is with HackEDU or not, please reach out to trainingplans@hackedu.io.