What Are Your Developers Missing in Application Security Training?
Key Takeaways
- AppSec tools catch problems too late: Application security scanners run after developers write the code, when fixing a vulnerability costs 30 times more than catching it earlier in the process.
- Secure developer habits require deliberate training: Many developers reach seniority without the cybersecurity awareness training to make secure coding instinctive, and one annual compliance-based session cannot build that habit.
- Sprint-level repetition drives behavior change: One hour per sprint, split between learning and applying it to real work, creates 26 security awareness training sessions across a year.
Security tooling investment in application security has grown steadily for years, but vulnerability rates have not moved in the same direction.
In a recent NINJIO webinar, Laura Bell Main, Founder and CEO of SafeStack, and Kevin Baroudi, NINJIO’s VP of Client Experience, examined why that gap persists and what organizations need to address the part of the problem that scanners and testing tools cannot reach.
Application Security Tools Are Solving the Wrong Part of the Problem
Most AppSec tools run at the back end of the software development lifecycle, after the design decisions and coding patterns that create vulnerabilities are already in place. By the time a scanner flags an issue, fixing it requires revisiting work that subsequent layers now rest on.
76% of applications contain at least one vulnerability, and 81% of organizations knowingly ship vulnerable code. Those figures have not improved meaningfully as security tooling investment has grown, because many AppSec tool investments investment target threat detection. To address the roots of the issue earlier, organizations need to look into where vulnerabilities originate; and this may be from the developers.
During the webinar, Laura put it this way:
“Imagine building a house and only scheduling inspectors after the first window is installed. Structural decisions made well before that window went in have already determined what can and cannot be fixed. AppSec tooling is doing the equivalent.”
Cybersecurity Awareness Training Wasn’t Built for the People Writing Code
Developers care about building high-quality software. As Laura noted during the webinar, assuming otherwise is “the biggest lie we tell ourselves in security.” What most developers have lacked is security training designed around how they actually work.
For most of its history, cybersecurity awareness training for developers was developed by people who review and audit code rather than write it.
Take for instance the OWASP Top 10, which has been in use for over 20 years and still features many of the same vulnerabilities it catalogued in 2004. It documents bugs that surfaced after software shipped. It was not built to help developers make better decisions earlier, during the build.
Laura’s argument is that cybersecurity belongs in the same mental framework as performance and scalability, but no one formally incorporated it into how organizations train and evaluate developers. She then explained a few reasons why:
Cybersecurity Expertise Arrives After Team Culture Is Already Set
SafeStack’s research found that most organizations do not bring in a dedicated AppSec professional until they reach around 150 engineers.
At that point, teams have established delivery rhythms and velocity expectations that do not include security as a cultural norm. The incoming AppSec hire’s first task can easily read as disrupting what is already working, regardless of intent.
Engineering and Security Teams Are Measured on Opposing Goals
Organizations measure engineering teams on speed and delivery, but they also keep cybersecurity teams accountable for risk reduction.
When those two incentives go unreconciled, cybersecurity becomes a source of friction between departments rather than a shared objective. Neither side is structured to succeed in that arrangement.
Cybersecurity Thinking Is Absent From Most Engineering Curricula
Developers build performance and reliability instincts through formal training and peer mentorship over years. Cybersecurity does not receive equivalent investment, which means most developers reach seniority without the mental models to make consistently secure decisions.
Cybersecurity Debt Compounds With Every Sprint
Cybersecurity debt refers to the insecure patterns, deferred decisions, and risky dependencies that accumulate when security is not part of the development process from the start.
Because software is additive and each layer rests on earlier decisions, unaddressed security gaps multiply with every release cycle. A vulnerability caught at the design stage costs minutes to address. The same vulnerability found after release can require weeks of remediation, with breach risk and compliance exposure on top of the engineering cost.
| Stage | When the Vulnerability Is Caught | Relative Cost to Fix |
| Design / Development | Early in the SDLC | Low (minutes to hours) |
| Code Review | Before deployment | Moderate (hours) |
| Post-Production | After release | High (days to weeks) |
Annual Compliance-based Cybersecurity Awareness Training Does Not Change How Developers Code
One-time, checkbox-style security awareness training has no measurable impact on the decisions developers make from sprint to sprint. Annual training doesn’t really work at all.
These programs fall short for predictable reasons.
- They run once and disappear from developers’ workflows: A module completed six months ago has no active presence in a developer’s decision-making during today’s sprint.
- They lack role-specific relevance: A Python developer building web APIs and a Java developer working on enterprise back-end systems face different security challenges and require personalized security coaching to address.
- They separate learning from application: Completing a module and answering multiple-choice questions does not build the habit of making secure decisions under delivery pressure. Behavior changes when people practice something repeatedly and can apply it immediately to real work.
A signal that cybersecurity awareness training isn’t working
When developers ask “how fast can I finish this?” rather than “how do I use this in my next sprint?”, the program is completing a requirement and does not change behavior.
The AI context adds additional pressure to this. As AI coding tools become standard in development workflows, developers shift from writing code to reviewing AI-generated output. The security knowledge they bring to that review becomes the critical variable, and a module completed months ago has no active presence when a developer is approving code under sprint pressure.
Secure Coding Education Needs to Fit Inside the Sprint
Effective secure coding education fits inside the sprint, which makes security practice part of how developers already work rather than something that competes with delivery timelines.
The 1 Hour of AppSec model
SafeStack’s framework, which NINJIO Secure Code is built around, is called the “1 Hour of AppSec” model: one hour per sprint per developer, split between 20 minutes of training and 40 minutes of applying what was covered.
Across 26 sprints in a year, that adds up to 26 hours of security practice, each session pairing learning with hands-on application. Whether the cybersecurity awareness training program is working shows up in how developers code in their next sprint, not in whether they completed the module.
What a Sprint-Compatible Secure Coding Program Covers
NINJIO Secure Code, powered by SafeStack, structures secure coding education across the full SDLC, from foundational security thinking through hands-on labs and professional certifications.
The program is modular by design so that teams can assign training by role, seniority, and development phase rather than routing every developer through the same generic sequence:
- Language-specific modules cover Python (with Flask and Django), Java, TypeScript, C#, .NET, and PHP, with new content added monthly based on feedback from the developer community and from organizations actively using the platform.
- SDLC-mapped learning paths give developers content relevant to their current phase of the build process, whether they are designing a new system or maintaining one no longer under active development.
- Hands-on labs extend training beyond developers to testers and designers, so security practice reaches the full team.
Whether a sprint-compatible program is working shows up in how developers approach their next sprint. Watch the full webinar to see how the platform supports that outcome.
Frequently Asked Questions
AppSec tools scan code after it is written. By that point, the design decisions and coding patterns that introduce vulnerabilities are already in place. Catching issues earlier in the SDLC costs a fraction of what post-production remediation requires.
Security debt is the insecure patterns and deferred design decisions that build up when security is absent from development from the start. Because software layers rest on earlier decisions, security debt multiplies with every sprint it goes unaddressed.
Allocating one hour per sprint, split between a short training session and applying what was learned to current work, is the most effective model. Developers build consistent security practice without stepping away from delivery for extended periods.
When AI generates code at speed, developers shift from writing to reviewing. The security knowledge a developer brings to that review still determines whether the code is safe, and that knowledge requires deliberate, ongoing training to build.
Compliance training fulfills a regulatory requirement through an annual event. Continuous education changes developer behavior through frequent, role-specific sessions tied to active work, improving the security decisions developers make every sprint.
