Thoughts on Developer Security Training
I have had the good fortune to have trained thousands of developers on Application Security. Private organizations, conferences and even some non-profit groups have engaged us (we45) and my team to do this. Needless to say, this has been an extremely rewarding experience. I have had several clients say that their developers are thinking more defensively, and that their security issues have significantly reduced over time. With each training, I have personally learned a lot
However, I hear a lot of opinions about training developers whenever I am at security conferences. Some of these opinions, in my opinion, are very different from the truth that I know. Some of them are even downright offensive to developers, where I have heard fellow security pros refer to developers as "idiots" and a lot worse.
Here are some of my thoughts on my experience so far with developer training
- Developers are far from "idiots". They solve complex challenges in this ever-changing landscape of application development and business requirements. They have to constantly educate themselves, process a ton of specifications and translate all of that into a working application, often under extremely tight deadlines. They have an intense job and many of them ace it with poise that many of my security industry kin can't do. For sure.
- Developers need to be challenged. They love challenges and the feeling of "solving a problem". Security Training, when oriented to challenge developers, works. Adding flavours of a CTF, challenge sessions on intentionally vulnerable apps, always helps.
- Developer Security Training needs to be a good bridge between Business Security Impact and Application Development. If you get them to understand impact, relevant to their organization (need not be deep) and their work-product, they are usually hooked.
- I like Richard Feynman's approach of "Teach Principles, not Formulas". I have seen several trainings that are just DOs and DONTs, where the trainer runs down libraries for Input Validation, Cryptography, etc that devs should use, without really going into "Why". Worse, sooner than later, those very libraries had breaches or exploits identified against them, which negated not only the recommendation (formula), but also reduced the "training" to a pointless TODO list. Explaining the various approaches to Input Validation, the pros and cons of each and then suggesting libraries, etc that would work, is a much better way of delivering Developer security training. They don't need you to teach them formulas. They have StackOverflow and several other sources for tactical guidance.
- Depending on your organization and its tech stack, your developers may often need more than "Application Security Training". They may need training on specific areas like Secrets Management, DevOps, Container Security, Kubernetes, Serverless etc. Understand the need and deliver the training, rather than forcing mandatory "AppSec Training" down their throats.
- Continuous Security Training in any form is a double-edged sword. I have seen orgs have mandatory monthly security trainings (Computer Based) where the developers need to play a game or check out a video on an AppSec topic. While that in itself is not bad, know that developers will find ways to bypass or skim over these initiatives.
- Cement knowledge with Playbooks. Playbooks could take the form of a simple guide that converts the knowledge from the training into a single page recipe. Have this recipe at their desks, their IDEs, JIRA, etc to be used as ready guides when they need them
Check out Abhay and we45's upcoming public trainings and talks here