What part does the human element play in the future of secure coding?
As the number of cyber-threats continues to grow, organizations are making daily trade-offs between security, practicality, and speed – exposing themselves to risks in the process. New approaches to secure coding are needed, so Secure Code Warrior engaged with Evans Data Corp. to conduct primary research into developers’ attitudes towards secure coding, secure code practices, and security operations (download the whitepaper here).
What this report revealed is that while ‘old-school’ reactive thinking still dominates, there is a growing awareness of the need for more proactive solutions, which turn developers themselves into the first line of defense.
Any exploration of the adoption of secure coding practices needs to begin with an understanding of the humans involved in its implementation, their perceptions of it, and their capacity to implement it. This then leads to the most important piece of the puzzle – how can they be empowered to code more securely right from the start and ship quality code faster, with confidence?
Secure coding – where are we now, and what has to change? Download the infographic 'The Human Element' now.
Current perspectives – reactive vs. proactive
When developers and development managers were asked about the activities they associate with secure coding, the top three responses were:
- Using scanning tools on deployed applications.
- Manually reviewing code for vulnerabilities.
- The active and ongoing practice of writing software that is protected from vulnerabilities.
As we can see, two of the top three responses still focused on reactive approaches – the first dependent on tooling (scanners), and the second on the developer (i.e. human) performing manual checks.
At the same time, two of the three activities nominated rely on the human element. This points to growing perceptions of security as a human issue. But of all the activities nominated, the most telling is No. 3, which identifies the human factor in writing software that is protected from vulnerabilities in the first place. This highlights a shift to starting left – a proactive and preventive approach that bakes security into software right from the start of the SDLC.
Where does security fit in the SDLC?
When developers and development managers are asked where they see secure code practices integrating into the SDLC, opinions differ. 55% of managers believe that secure coding is integrated across the entire development process, compared with only 43% of developers. The difference might reflect these two groups’ differing roles within the SDLC. Management is typically less involved with the actual work of coding and tends to have a higher-level view – whereas developers might be more concerned with the nuts and bolts.
But from an overall security and code quality point of view, what’s alarming is that only 13% of developers and 10% of managers saying that secure code practices should be integrated within the design stages – right at the start of the SDLC. This is a huge and unrealized opportunity. According to an IBM study, it is thirty times more expensive to fix vulnerabilities in post-release code than if they were found and remediated at the beginning.1 That’s a powerful incentive for a new proactive and human-led defense of software security, that equips developers to code more securely, right from the start. Software security can’t be resolved by reliance on tooling alone – it has to take account of the human element.
Is the human element prepared?
97% of developers surveyed believe they have had sufficient training in secure coding, and 95% agreed that training in secure coding had been valuable to their career. But before accepting these claims at face value, we need to ask: Why are code vulnerabilities still so prevalent? Are developer’s claims of secure code expertise just a case of human ego? The evidence certainly points in this direction. In a more modest admission, more than 88% of surveyed developers admit that secure coding is difficult to learn, and 91% of development managers acknowledge that secure coding practices are challenging to implement. When asked to identify their major personal concerns around secure code implementation, 28% of developers find the learning process challenging, while 24% find the learning process boring. This points to the fact that developer training needs to improve.
What does the human element need?
To overcome the ‘challenging’ factor, worthwhile secure training requires a ‘scaffolding’ process that supports the developer to build secure coding skills step by step. For maximum relevance and immediate applicability, that training should take place in the specific language:framework they use every day.
To overcome the ‘boredom’ factor, secure code training needs to be delivered in hands-on ways — proven to be far more engaging for developers than outdated classroom or ‘watch this video’ models. These should include live simulations that allow developers to tackle sometimes-risky security challenges in a safe environment. The aim should be to teach developers how to find and fix vulnerabilities in code as they work and make secure coding part of their day-to-day flow. Another key enabling factor is inside-the-IDE linting and coaching, which helps developers constantly learn and up-skill as they code, preventing and eliminating vulnerabilities as they go.
If you’d like to find out how to provide your developers with this new level of developer-centered tools and training, book a demo now.
You can also download your copy of the whitepaper Shifting from reaction to prevention: The changing face of application security.
.avif)
.avif)
As the number of cyber-threats continues to grow, organizations are making daily trade-offs between security, practicality, and speed – exposing themselves to risks in the process.
Secure Code Warrior makes secure coding a positive and engaging experience for developers as they increase their skills. We guide each coder along their own preferred learning pathway, so that security-skilled developers become the everyday superheroes of our connected world.

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 demoSecure Code Warrior makes secure coding a positive and engaging experience for developers as they increase their skills. We guide each coder along their own preferred learning pathway, so that security-skilled developers become the everyday superheroes of our connected world.
This article was written by Secure Code Warrior's team of industry experts, committed to empowering developers with the knowledge and skills to build secure software from the start. Drawing on deep expertise in secure coding practices, industry trends, and real-world insights.
.avif)
.avif)
As the number of cyber-threats continues to grow, organizations are making daily trade-offs between security, practicality, and speed – exposing themselves to risks in the process. New approaches to secure coding are needed, so Secure Code Warrior engaged with Evans Data Corp. to conduct primary research into developers’ attitudes towards secure coding, secure code practices, and security operations (download the whitepaper here).
What this report revealed is that while ‘old-school’ reactive thinking still dominates, there is a growing awareness of the need for more proactive solutions, which turn developers themselves into the first line of defense.
Any exploration of the adoption of secure coding practices needs to begin with an understanding of the humans involved in its implementation, their perceptions of it, and their capacity to implement it. This then leads to the most important piece of the puzzle – how can they be empowered to code more securely right from the start and ship quality code faster, with confidence?
Secure coding – where are we now, and what has to change? Download the infographic 'The Human Element' now.
Current perspectives – reactive vs. proactive
When developers and development managers were asked about the activities they associate with secure coding, the top three responses were:
- Using scanning tools on deployed applications.
- Manually reviewing code for vulnerabilities.
- The active and ongoing practice of writing software that is protected from vulnerabilities.
As we can see, two of the top three responses still focused on reactive approaches – the first dependent on tooling (scanners), and the second on the developer (i.e. human) performing manual checks.
At the same time, two of the three activities nominated rely on the human element. This points to growing perceptions of security as a human issue. But of all the activities nominated, the most telling is No. 3, which identifies the human factor in writing software that is protected from vulnerabilities in the first place. This highlights a shift to starting left – a proactive and preventive approach that bakes security into software right from the start of the SDLC.
Where does security fit in the SDLC?
When developers and development managers are asked where they see secure code practices integrating into the SDLC, opinions differ. 55% of managers believe that secure coding is integrated across the entire development process, compared with only 43% of developers. The difference might reflect these two groups’ differing roles within the SDLC. Management is typically less involved with the actual work of coding and tends to have a higher-level view – whereas developers might be more concerned with the nuts and bolts.
But from an overall security and code quality point of view, what’s alarming is that only 13% of developers and 10% of managers saying that secure code practices should be integrated within the design stages – right at the start of the SDLC. This is a huge and unrealized opportunity. According to an IBM study, it is thirty times more expensive to fix vulnerabilities in post-release code than if they were found and remediated at the beginning.1 That’s a powerful incentive for a new proactive and human-led defense of software security, that equips developers to code more securely, right from the start. Software security can’t be resolved by reliance on tooling alone – it has to take account of the human element.
Is the human element prepared?
97% of developers surveyed believe they have had sufficient training in secure coding, and 95% agreed that training in secure coding had been valuable to their career. But before accepting these claims at face value, we need to ask: Why are code vulnerabilities still so prevalent? Are developer’s claims of secure code expertise just a case of human ego? The evidence certainly points in this direction. In a more modest admission, more than 88% of surveyed developers admit that secure coding is difficult to learn, and 91% of development managers acknowledge that secure coding practices are challenging to implement. When asked to identify their major personal concerns around secure code implementation, 28% of developers find the learning process challenging, while 24% find the learning process boring. This points to the fact that developer training needs to improve.
What does the human element need?
To overcome the ‘challenging’ factor, worthwhile secure training requires a ‘scaffolding’ process that supports the developer to build secure coding skills step by step. For maximum relevance and immediate applicability, that training should take place in the specific language:framework they use every day.
To overcome the ‘boredom’ factor, secure code training needs to be delivered in hands-on ways — proven to be far more engaging for developers than outdated classroom or ‘watch this video’ models. These should include live simulations that allow developers to tackle sometimes-risky security challenges in a safe environment. The aim should be to teach developers how to find and fix vulnerabilities in code as they work and make secure coding part of their day-to-day flow. Another key enabling factor is inside-the-IDE linting and coaching, which helps developers constantly learn and up-skill as they code, preventing and eliminating vulnerabilities as they go.
If you’d like to find out how to provide your developers with this new level of developer-centered tools and training, book a demo now.
You can also download your copy of the whitepaper Shifting from reaction to prevention: The changing face of application security.
.avif)
As the number of cyber-threats continues to grow, organizations are making daily trade-offs between security, practicality, and speed – exposing themselves to risks in the process. New approaches to secure coding are needed, so Secure Code Warrior engaged with Evans Data Corp. to conduct primary research into developers’ attitudes towards secure coding, secure code practices, and security operations (download the whitepaper here).
What this report revealed is that while ‘old-school’ reactive thinking still dominates, there is a growing awareness of the need for more proactive solutions, which turn developers themselves into the first line of defense.
Any exploration of the adoption of secure coding practices needs to begin with an understanding of the humans involved in its implementation, their perceptions of it, and their capacity to implement it. This then leads to the most important piece of the puzzle – how can they be empowered to code more securely right from the start and ship quality code faster, with confidence?
Secure coding – where are we now, and what has to change? Download the infographic 'The Human Element' now.
Current perspectives – reactive vs. proactive
When developers and development managers were asked about the activities they associate with secure coding, the top three responses were:
- Using scanning tools on deployed applications.
- Manually reviewing code for vulnerabilities.
- The active and ongoing practice of writing software that is protected from vulnerabilities.
As we can see, two of the top three responses still focused on reactive approaches – the first dependent on tooling (scanners), and the second on the developer (i.e. human) performing manual checks.
At the same time, two of the three activities nominated rely on the human element. This points to growing perceptions of security as a human issue. But of all the activities nominated, the most telling is No. 3, which identifies the human factor in writing software that is protected from vulnerabilities in the first place. This highlights a shift to starting left – a proactive and preventive approach that bakes security into software right from the start of the SDLC.
Where does security fit in the SDLC?
When developers and development managers are asked where they see secure code practices integrating into the SDLC, opinions differ. 55% of managers believe that secure coding is integrated across the entire development process, compared with only 43% of developers. The difference might reflect these two groups’ differing roles within the SDLC. Management is typically less involved with the actual work of coding and tends to have a higher-level view – whereas developers might be more concerned with the nuts and bolts.
But from an overall security and code quality point of view, what’s alarming is that only 13% of developers and 10% of managers saying that secure code practices should be integrated within the design stages – right at the start of the SDLC. This is a huge and unrealized opportunity. According to an IBM study, it is thirty times more expensive to fix vulnerabilities in post-release code than if they were found and remediated at the beginning.1 That’s a powerful incentive for a new proactive and human-led defense of software security, that equips developers to code more securely, right from the start. Software security can’t be resolved by reliance on tooling alone – it has to take account of the human element.
Is the human element prepared?
97% of developers surveyed believe they have had sufficient training in secure coding, and 95% agreed that training in secure coding had been valuable to their career. But before accepting these claims at face value, we need to ask: Why are code vulnerabilities still so prevalent? Are developer’s claims of secure code expertise just a case of human ego? The evidence certainly points in this direction. In a more modest admission, more than 88% of surveyed developers admit that secure coding is difficult to learn, and 91% of development managers acknowledge that secure coding practices are challenging to implement. When asked to identify their major personal concerns around secure code implementation, 28% of developers find the learning process challenging, while 24% find the learning process boring. This points to the fact that developer training needs to improve.
What does the human element need?
To overcome the ‘challenging’ factor, worthwhile secure training requires a ‘scaffolding’ process that supports the developer to build secure coding skills step by step. For maximum relevance and immediate applicability, that training should take place in the specific language:framework they use every day.
To overcome the ‘boredom’ factor, secure code training needs to be delivered in hands-on ways — proven to be far more engaging for developers than outdated classroom or ‘watch this video’ models. These should include live simulations that allow developers to tackle sometimes-risky security challenges in a safe environment. The aim should be to teach developers how to find and fix vulnerabilities in code as they work and make secure coding part of their day-to-day flow. Another key enabling factor is inside-the-IDE linting and coaching, which helps developers constantly learn and up-skill as they code, preventing and eliminating vulnerabilities as they go.
If you’d like to find out how to provide your developers with this new level of developer-centered tools and training, book a demo now.
You can also download your copy of the whitepaper Shifting from reaction to prevention: The changing face of application security.

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 demoSecure Code Warrior makes secure coding a positive and engaging experience for developers as they increase their skills. We guide each coder along their own preferred learning pathway, so that security-skilled developers become the everyday superheroes of our connected world.
This article was written by Secure Code Warrior's team of industry experts, committed to empowering developers with the knowledge and skills to build secure software from the start. Drawing on deep expertise in secure coding practices, industry trends, and real-world insights.
As the number of cyber-threats continues to grow, organizations are making daily trade-offs between security, practicality, and speed – exposing themselves to risks in the process. New approaches to secure coding are needed, so Secure Code Warrior engaged with Evans Data Corp. to conduct primary research into developers’ attitudes towards secure coding, secure code practices, and security operations (download the whitepaper here).
What this report revealed is that while ‘old-school’ reactive thinking still dominates, there is a growing awareness of the need for more proactive solutions, which turn developers themselves into the first line of defense.
Any exploration of the adoption of secure coding practices needs to begin with an understanding of the humans involved in its implementation, their perceptions of it, and their capacity to implement it. This then leads to the most important piece of the puzzle – how can they be empowered to code more securely right from the start and ship quality code faster, with confidence?
Secure coding – where are we now, and what has to change? Download the infographic 'The Human Element' now.
Current perspectives – reactive vs. proactive
When developers and development managers were asked about the activities they associate with secure coding, the top three responses were:
- Using scanning tools on deployed applications.
- Manually reviewing code for vulnerabilities.
- The active and ongoing practice of writing software that is protected from vulnerabilities.
As we can see, two of the top three responses still focused on reactive approaches – the first dependent on tooling (scanners), and the second on the developer (i.e. human) performing manual checks.
At the same time, two of the three activities nominated rely on the human element. This points to growing perceptions of security as a human issue. But of all the activities nominated, the most telling is No. 3, which identifies the human factor in writing software that is protected from vulnerabilities in the first place. This highlights a shift to starting left – a proactive and preventive approach that bakes security into software right from the start of the SDLC.
Where does security fit in the SDLC?
When developers and development managers are asked where they see secure code practices integrating into the SDLC, opinions differ. 55% of managers believe that secure coding is integrated across the entire development process, compared with only 43% of developers. The difference might reflect these two groups’ differing roles within the SDLC. Management is typically less involved with the actual work of coding and tends to have a higher-level view – whereas developers might be more concerned with the nuts and bolts.
But from an overall security and code quality point of view, what’s alarming is that only 13% of developers and 10% of managers saying that secure code practices should be integrated within the design stages – right at the start of the SDLC. This is a huge and unrealized opportunity. According to an IBM study, it is thirty times more expensive to fix vulnerabilities in post-release code than if they were found and remediated at the beginning.1 That’s a powerful incentive for a new proactive and human-led defense of software security, that equips developers to code more securely, right from the start. Software security can’t be resolved by reliance on tooling alone – it has to take account of the human element.
Is the human element prepared?
97% of developers surveyed believe they have had sufficient training in secure coding, and 95% agreed that training in secure coding had been valuable to their career. But before accepting these claims at face value, we need to ask: Why are code vulnerabilities still so prevalent? Are developer’s claims of secure code expertise just a case of human ego? The evidence certainly points in this direction. In a more modest admission, more than 88% of surveyed developers admit that secure coding is difficult to learn, and 91% of development managers acknowledge that secure coding practices are challenging to implement. When asked to identify their major personal concerns around secure code implementation, 28% of developers find the learning process challenging, while 24% find the learning process boring. This points to the fact that developer training needs to improve.
What does the human element need?
To overcome the ‘challenging’ factor, worthwhile secure training requires a ‘scaffolding’ process that supports the developer to build secure coding skills step by step. For maximum relevance and immediate applicability, that training should take place in the specific language:framework they use every day.
To overcome the ‘boredom’ factor, secure code training needs to be delivered in hands-on ways — proven to be far more engaging for developers than outdated classroom or ‘watch this video’ models. These should include live simulations that allow developers to tackle sometimes-risky security challenges in a safe environment. The aim should be to teach developers how to find and fix vulnerabilities in code as they work and make secure coding part of their day-to-day flow. Another key enabling factor is inside-the-IDE linting and coaching, which helps developers constantly learn and up-skill as they code, preventing and eliminating vulnerabilities as they go.
If you’d like to find out how to provide your developers with this new level of developer-centered tools and training, book a demo now.
You can also download your copy of the whitepaper Shifting from reaction to prevention: The changing face of application security.
Table of contents
Secure Code Warrior makes secure coding a positive and engaging experience for developers as they increase their skills. We guide each coder along their own preferred learning pathway, so that security-skilled developers become the everyday superheroes of our connected world.

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
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peak of what our content catalog has to offer by topic and role.
Quests: Industry leading learning to keep developers ahead of the game mitigating risk.
Quests is a learning platform that helps developers mitigate software security risks by enhancing their secure coding skills. With curated learning paths, hands-on challenges, and interactive activities, it empowers developers to identify and prevent vulnerabilities.
Resources to get you started
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
The Decade of the Defenders: Secure Code Warrior Turns Ten
Secure Code Warrior's founding team has stayed together, steering the ship through every lesson, triumph, and setback for an entire decade. We’re scaling up and ready to face our next chapter, SCW 2.0, as the leaders in developer risk management.