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!
Chief Executive Officer, Chairman, and Co-Founder
Click on the link below and download the PDF of this one pager.
DownloadSecure 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
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.