The DevSecOps practice is increasingly gaining in popularity as more businesses recognise the value of taking shared responsibility for security, ‘shifting left’ and getting it right from the start
The power of a security-aware software developer should never be underestimated; their bright minds can thwart vulnerabilities and improve your security posture. How well, however, depends on the type of secure code training they receive. Low-effort solutions, which are usually only driven by the need to meet regulations, are typically insufficient, and the focus needs to shift to building the skills of developers via dynamic and contextually relevant tuition.
Enabling layered learning
The developer should be central to a preventative security strategy, right there at the code level upwards. The proof is in the pudding with the recent and sadly devastating Log4Shell vulnerability that could have been prevented with higher quality coding patterns. The defensive techniques that businesses can engage to upskill developers do indeed vary, even if they can rightly exist in the same training bucket.
Let’s take baking a cake as an example. How well do you think your cake would turn out if your recipe was purely based on what not to do? The instructions of “Don’t forget the eggs!” and “Don’t overbake it!” leave it open for interpretation and encourage mistakes. The same is true for security education. Telling developers what not to do is not exactly setting them up for success. It offers no practical guidance to truly switch on and embrace defensive mindsets. You can tell them “Don’t misconfigure that API”, but with no knowledge of what constitutes secure configuration, errors can and will easily creep in.
To reduce vulnerabilities, developers need a foundational understanding of how they work, why they are dangerous, what coding patterns cause them, and what patterns can fix them. A scaffolded approach allows layers of knowledge to give a full picture of what it means to code securely, defend a codebase, and stand up as a security-aware developer. Part of that layered learning should be dedicated to offense and grasping the attacker’s mindset to hone invaluable lateral thinking skills in threat modelling and defensive strategy.
Stop reinforcing bad habits
Bad habits can persist from even the most effectively structured developer learning methods, even if they are able to effectively validate code security. There’s also the quality issue, with the definition of “quality” still up for debate. While high-quality code needs to be the baseline of all software development, insecure code simply can’t be deemed high-quality, despite its potentially high functionality. That being said, secure code doesn’t mean that high-quality is a given, as some poor coding patterns can fix one issue while introducing another at the same time, or even completely break the software.
This encouragement of poor coding patterns is easy though, especially if the software feature is cool enough to forget about the bugs. After all, developers prioritise and take pride in building these features, and generally view security as the responsibility of their AppSec counterparts. This mindset has got to change.
The problem also lies in the way some learning pathways encourage hands-on code remediation as it potentially reinforces code that is secure, but of substandard quality. By applying a binary “Yes, this is secure” and “No, this is not secure” assessment, rather than looking deeper into whether it is truly the best approach to resolve the bug and maintain software integrity, there are devils in the detail that go unnoticed. You wouldn’t pass a driving test if you ran through a red light on your exam, would you? Without taking developers through the entire process for a complete view of secure coding, this approach only perpetuates the same issues it’s trying to solve.
Putting security at the forefront of developer priorities
If training sparks boredom, not curiosity, it’s an instant educational failure. If all developers can think about when asked to participate in training is the deadlines they are missing, it’s high time to change the approach. It is unfair to ask developers to flip their days on their heads to prioritise training. At the same time, there must be strong importance placed on helping them build the right skills and empower them to care about implementing secure coding patterns from the start.
One way to achieve this is by incentivising, recognising and rewarding developers for regularly engaging with security skill-building. Injecting healthy competitions into their workflows will also strengthen the security culture and developer engagement in the secure software building process. By following this approach, organisations can enable layered learning to encourage a foundational understanding among developers, reduce the incidence of bad habits and ultimately enable higher-quality and security-conscious coding patterns.
About the Author
Matias Madou is the Co-Founder & CTO at Secure Code Warrior He is a researcher and developer with more than 15 years of hands-on software security experience and has developed solutions for companies such as HP Fortify. Over his career, Madou has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, he has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DEFCON, BSIMM, OWASP AppSec, and BruCon. Madou holds a Ph.D. in computer engineering from Ghent University.
Featured image: ©Maciek905
