Incentivizing developers is the key to better security practices
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, it if 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 their skilled programmers, it can hardly expect their developers to suddenly gain new skills and put them into action in a meaningful way that actively reduces vulnerabilities.
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!
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.
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoChief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
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, it if 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 their skilled programmers, it can hardly expect their developers to suddenly gain new skills and put them into action in a meaningful way that actively reduces vulnerabilities.
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!
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, it if 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 their skilled programmers, it can hardly expect their developers to suddenly gain new skills and put them into action in a meaningful way that actively reduces vulnerabilities.
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!
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoChief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
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, it if 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 their skilled programmers, it can hardly expect their developers to suddenly gain new skills and put them into action in a meaningful way that actively reduces vulnerabilities.
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!
Table of contents
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Resources to get you started
10 Key Predictions: Secure Code Warrior on AI & Secure-by-Design’s Influence in 2025
Organizations are facing tough decisions on AI usage to support long-term productivity, sustainability, and security ROI. It’s become clear to us over the last few years that AI will never fully replace the role of the developer. From AI + developer partnerships to the increasing pressures (and confusion) around Secure-by-Design expectations, let’s take a closer look at what we can expect over the next year.
OWASP Top 10 For LLM Applications: What’s New, Changed, and How to Stay Secure
Stay ahead in securing LLM applications with the latest OWASP Top 10 updates. Discover what's new, what’s changed, and how Secure Code Warrior equips you with up-to-date learning resources to mitigate risks in Generative AI.
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.