For too long Security vs Development has been an unfair game. I believe this, as someone who sits on both sides of the fence. I am a life-long developer who started coding before I was 11 years old, and now has 12 patents under my belt. I also have more than 15 years of hands-on software security experience, including involvement in multiple AppSec research projects which led to commercial products. I also deliver advanced AppSec training courses.
I care deeply about both software development and software security, and I understand the very real tension between developers and security teams.
Here's how the "Dev Vs Security" game goes:
Let's call our developer "Dev". He considers himself a fairly skilled and experienced developer. We'll call our appsec manager "Sec", and like many software security professionals, Sec has minimal developer background or has left the development field long time ago. His job is to look for problems in Dev's code, with a plethora of tools to assist him.
Tension begins at the outset: Dev needs to create functionally correct code without any security issues, while Sec's job is to find problems, which feels like a much easier task.
Sec himself is responsible for security across about 50 developers and is an expert in security policy and identifying security problems in code. He's stretched, stressed, and not trained to fix the issues he finds. He needs Dev to do the fixing. Dev wouldn't mind helping, but he has no spare time or tools to help him.
Tension starts to rise when Sec tells Dev his code is broken. Dev takes pride in his work and believes he has written functionally correct code, and now feels unfairly threatened. He definitely doesn't feel like Sec is helping him, but rather, adding unnecessary burdens to his already very full plate. He wrote that code months ago and has moved on to another project in a different language. He will need to refresh his memory about the language, the code and the task itself to resolve "Sec's problem". Why doesn't Sec fix it?!
Dev and his team are creators, taught to build features and applications. They receive minimal training for compliance that's too high level and not language specific. They don't know how to code securely or how to fix these problems that Sec keeps throwing at them. Security has become a much bigger issue since a security breach was written about in the media!
Sec needs the problems investigated and fixed. His job depends on it. Dev wants more proof the problem actually exists but really, he wants to move on to building his features. New app development is what fuels his employment. The game goes on. It's not fun. There are no winners.
Sound familiar? Although somewhat simplified I am sure both developers and security professionals know this pain.
One of the big drivers of the problem is that the vast majority of current application security tools focus on moving from right to left in the Software Development Life Cycle (SLDC). This approach supports detection of vulnerabilities in written code and then fixing them. Apart from the developer-security angst described above, it is about 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them when writing code in the IDE.
It's time to change the game. Imagine if developers were taught to write secure code in real time, and to avoid creating many of the bugs in the first place? Imagine if they could fix secure coding problems as they arise? Imagine if highly skilled security managers and testers could focus on finding and fixing the really challenging, complex bugs rather than sending developers after nebulous minor issues with limited instructions?
That's the reason I co-founded Secure Code Warrior. We have built an online, hands-on, gamified SaaS Learning Platform that actively engages developers to learn and build their secure coding skills. Within the platform, we also have a real-time coaching and correction plug-in that helps developers as they write, from the first line of code. Secure Code Warrior genuinely starts at the extreme left of the SDLC, preventing vulnerabilities by empowering developers to write secure code and teaching them as they work.
We don't believe in training people once—using slides, videos, or clickable animations; or using abstract concepts you cannot apply directly in your code. We believe in continuous learning through short, hands-on challenges in specific coding frameworks and confronting developers with different vulnerabilities in multiple scenarios. We believe in real-time mentoring of developers that is useful and practical. Developers simply cannot learn about SQL injection through one example. They need exposure to multiple examples of this OWASP vulnerability to recognise this dangerous coding pattern.
I am speaking at InfoSec World and will be running a Secure Coding Tournament as part of the Tech Labs track. For developers, it's a great way to start to embrace the security challenge in a positive and fun way. And for security professionals who want to learn more about secure coding, it's a great way to embrace and understand coding challenges. I encourage developers of any level to come and play; challenge yourself to be crowned our "Secure Code Warrior". We'll offer training appropriate for all levels; skip through easy puzzles and move on to the more challenging games, if it suits you. This is a win-win game for developers and security.
Do you want to learn some secure coding techniques? Matias will lead a Tech Lab at InfoSec World 2018, on Monday, March 19th.