Skip to content

How To Create a Successful Secure Coding Training Plan

How To Create a Successful Secure Coding Training Plan

Published on

Developing a secure coding training plan for developers and Quality Assurance engineers can be a challenge. How can you develop a plan that reduces vulnerabilities, doesn’t take time away from product development, and will keep learners engaged?

Based on our work with hundreds of organizations and tens of thousands of developers, we have developed our list of best practices. This list came about through a lot of experience and trial and error over the years. 

Of course, every organization is unique, so every single one of our best practices might not be applicable to you. To get the most from this list, make it a goal to optimize in as many areas as possible to build the most effective secure coding training plan that works for your organization.

Here are the things we consider essential for a well-rounded training plan.

Hands-On Training Content

Hands-on training, requiring developers to actually code, is highly recommended. This ensures that developers are practicing what they are learning and gaining experience in the outcome -- secure coding. While various forms of training delivery, including multiple-choice lessons, videos, and slides, have their place in overall application security training, nothing is as effective as real hands-on coding to solidify developer skills.

Our experience, and that of our customers, bears that out. Companies that have tried only videos or slides for developer training have concluded it is not effective because developers are simply not engaged. They also don't have an opportunity to practice the skills they have learned.

Developers enjoy solving problems and writing code, not watching videos or slides. Offering your developers a live application sandbox environment where they can test their knowledge has a tremendously positive impact.

Hands-on training should include both offensive and defensive approaches. Developers should practice finding and fixing vulnerabilities in code and also learn how to recognize and avoid vulnerabilities in the first place.

Offensive application security gives developers a deep understanding of the mechanics and fundamentals of vulnerabilities so they can think through multiple attack scenarios and better defend against a breach.

 

Ongoing Training Schedule

Training as a one-time event, rather than following a consistent cadence throughout the year, is not as effective and leads to push back from developers. Developers do not want to be forced to take training in bulk in a compact timeframe, such as one week or even one day.

Developers have a lot of priorities, so on-demand training they can consume in shorter, manageable bites often works better with their schedule. In addition, it makes developers feel like they have more ownership of their training, leading to higher engagement.

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, no more than one to two hours of training should be scheduled every month so developers are not distracted from developing. This also allows security skills to more solidly build over time.

Of course, sometimes there are compliance deadlines you need to meet and it’s not always possible to spread training out throughout the year. If there is a compliance deadline, then only those lessons required for compliance should be taken in a compact timeframe. After that, additional lessons at the one to two hours per month pace should be assigned to build and reinforce secure coding knowledge.

Diverse Training Topics

Developers should receive unique training plans based on their role and expertise. All developers should go through the Open Web Application Security Project (OWASP) Top 10 lessons to ensure a basic understanding of the most common threats and vulnerabilities plus strategies to prevent them. 

Training results should be tracked, so learning administrator can quickly address areas that need reinforcement for individual developers.

Below are our role-based training recommendations.

Backend Developer

  • 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

  • OWASP Top 10
  • Cross-Site Request Forgery
  • JSON Web Token (JWT) Authentication Security (if applicable)
  • Cross-Site Scripting (XSS) Advanced
  • 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 actual coding lessons may be beneficial. In addition, having challenges or labs they can go through to practice finding vulnerabilities and using a web proxy is important.

  • 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 have advanced knowledge and should focus on lessons that go through real-world examples. These type of lessons tend to be more nuanced and can sometimes rely on several vulnerabilities for the application to be exploitable.

  • OWASP Top 10
  • 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)

Ready to start building your own secure coding training plan? We're here to help. Reach out to support@securityjourney.com and we'll gladly answer your questions and offer our advice.