Why Secure Code Training Sucks

Your secure code training has already failed, if making it mandatory is the only way to get your developers onboard.

With the super rapid pace of changes in technology stacks, the introduction of AI code assistants, and new software architectures, how do you imagine developers learn and adapt to these new changes? If you think they go through video tutorial courses, you’re mistaken. Many new tech stacks don’t even come with proper documentation, let alone a training lab!

Developers are problem-solvers and like to experiment. They know how to break down problems into sub-problems and tackle each one individually. Facing new challenges and adapting solutions is part of their daily routine. They self-learn bit by bit—not from step-by-step training, but from trying, failing, and pivoting. They’ve built muscle for that.

When it comes to security, however, it seems they don’t see it as a problem. Why is that? Perhaps they’re unaware of the security implications of their coding and design decisions. Naturally, we plan to train them, but a typical secure code training usually looks like this:

1. A learning pathway, likely based on compliance requirements.
2. Outdated vulnerabilities and code examples rarely seen in modern cloud-native applications.
3. Retrofitting vulnerabilities into programming languages rarely used in practice for those use cases.
4. Hand-holding developers with step-by-step tutorials (e.g., do this, don’t do that).
5. Restricting developers to specific tools for understanding and patching vulnerabilities.
6. Forcing developers into a single way of fixing vulnerabilities (e.g., “use this function,” “don’t use that library”).

Are we still wondering why this doesn’t work? These approaches are completely alien to how developers actually learn. As Persian Rumi put it: when you plant wheat, how you expect barley to grow?!
If we’re serious about getting developers on board with security, we need a radical change in our approach—one that aligns with their natural way of learning. You need to pivot from traditional training to providing learning sandboxes where they can play and experiment:

1. Present security as a software engineering problem.
2. Describe vulnerabilities using developer-friendly terminology.
3. Clearly demonstrate the significance of each vulnerability.
4. Avoid hand-holding.
5. Avoid forcing a single solution.
6. Avoid limiting developers with specific tools. They each have their own toolkit for investigating issues.
7. Avoid providing solutions straight away.
8. Allow developers to experiment different solutions.
9. Let them try, fail, and pivot!

I’ve had the opportunity to work with hundreds of development teams, from small SaaS startups to Fortune 500 enterprises. I’ve seen firsthand that using this new approach genuinely works and delivers the results we need.