Professional developers want to embrace DevSecOps and write secure code, but their organizations need to support this seachange if they want that effort to grow.
The cyber threat landscape is becoming more complex by the day. Attackers are constantly scanning networks for vulnerable applications, programs, cloud instances, and the latest flavor of the month is APIs, widely considered an easy win thanks to their often lax security controls.
They are so persistent that new apps can sometimes be compromised and exploited within hours of deployment. The Verizon 2021 Data Breach Investigations Report makes it very clear that the threats leveled against businesses and organizations are more dangerous today than at any other point in history.
It's becoming very clear that the only way to truly fortify the software being created is to ensure that it's built on secure code. In other words, the best way to stop the threat actor invasion is to deny them a foothold into your applications in the first place. Once you start fighting that war, most of the advantages are skewed towards the attackers.
This situation first gave rise to agile development and DevOps, and later to the entire DevSecOps movement, where security is a shared responsibility for everyone involved in the process of creating software from development to deployment. But the base of that pyramid, and arguably the most important part, are the developers. While most developers want to do their part and write secure code, many of the organizations they work for are less supportive of the changes such a major shift in priorities requires.
Defeat by Design
For many years, developers were told that their primary role at their organizations was to quickly build and deploy apps in a fast-paced environment, where business never stops and customers never sleep. The faster that developers could code and the more features they could deploy, the more valuable they were seen in terms of their performance reviews.
Security was an afterthought, if it was considered at all. Instead, all of that was left to the application security (AppSec) teams to figure out. AppSec teams were disliked by most developers because they would often send completed applications back into development to apply security patches or to rewrite code to remediate vulnerabilities. And every hour that a developer spent working on an app that was already "finished" was an hour they were not creating new apps and features, thus decreasing their performance (and their value, in the eyes of a particularly punitive company).
And then the threat environment changed the importance and prioritization of security for most companies. According to the recent Cost of a Data Breach Report from IBM and the Ponemon Institute, the average cybersecurity breach now costs about $3.8 million per incident, although that is hardly the upper limit. One company alone incurred $1.3 billion in losses following a breach on their network. The companies of today want the security offered by DevSecOps, but, sadly, have been slow to reward developers who answer that call.
Simply telling the development teams to consider security won't work, especially if they are still being incentivized based on speed alone. In fact, within such a system, developers who take the time to learn about security and secure their code could actually be losing out on better performance reviews and lucrative bonuses that their less-security-aware colleagues continue to earn. It's almost like companies are unwittingly rigging the system for their own security failures, and it comes back to their perception of the development team. If they're not seeing them as the security frontlines, then it's very unlikely a viable plan to utilize their workforce will come to fruition.
And this doesn't even account for the lack of training. Some very skilled developers have decades of experience coding, but very little when it comes to security… after all, it was never required of them. Unless a company provides a good training program to its skilled programmers, it can hardly expect its developers to suddenly gain new skills and put them into action in a meaningful way that actively reduces vulnerabilities.
(Are you already security-confident and want to compete against other secure coding all-stars? Join Secure Code Warrior's Devlympics 2021, our biggest and best global security tournament, and you could win big!)
Rewarding Developers for Good Security Practices
The good news is that the overwhelming majority of developers do their job because they find it both challenging and rewarding, and because they enjoy the respect that their position entails.
Lifelong professional coder Michael Shpilt recently wrote about all of the things that motivate him and his coding colleagues in their development work. Yes, he lists monetary compensation among those incentives, but it's surprisingly far down the list. Instead, he prioritizes the thrill of creating something new, learning new skills and the satisfaction of knowing that his work is going to be directly used to help others. He also talks about wanting to feel valued within his company and community. In short, developers are like a lot of good people who take pride in their work.
Developers like Shpilt and others don't want threat actors compromising their code and using it to harm their company, or the very users they are trying to help. But, they can't suddenly shift their priorities to security without support. Otherwise, It's almost like the system will be working against them.
To help development teams improve their cybersecurity prowess, they must first be taught the necessary skills. Utilizing scaffolded learning, and tools like Just-in-Time (JiT) training can make this process much less painful, and helps to build upon existing knowledge in the right context.
The principle of JiT is that developers are served the right knowledge at just the right time, for example, if a JiT developer training tool detects that a programmer is creating an insecure piece of code, or is accidentally introducing a vulnerability into their application, it can activate and show the developer how they could fix that problem, and how to write more secure code to perform that same function in the future.
With a commitment to upskilling in place, the old methods of evaluating developers based solely on speed need to be eliminated. Instead, coders should be rewarded based on their ability to create secure code, with the best developers becoming security champions that help the rest of the team improve their skills. And those champions need to be rewarded with both company prestige and monetary compensation. It's also important to remember that developers don't typically have a positive experience with security, and uplifting them with positive, fun learning and incentives that speak to their interests will go a long way to ensuring both knowledge retention and a desire to keep building skills.
Companies can still include coding speed as one part of a developer's evaluation, but with the expectation that developing secure applications might take a little longer, especially as coders are learning those new skills.
DevSecOps can be the ultimate defense against the dark arts of an increasingly dangerous threat landscape. Just don't forget that the champions of this new world, the developers who are consistently creating new code, need to be respected and compensated for their work.
Want to put your security skills to the test against other developers all over the world? Check out Secure Code Warrior's Devlympics 2021, and you could take out a major prize in our global tournaments!
