Your developers know security matters.
They know what injection is. They understand why access controls matter. They know dependencies can introduce risk. They have reviewed code, fixed vulnerabilities, debated design decisions, and probably spent more time thinking about application security than most people in the organization.
They are also trying to ship software.
There are deadlines. Production issues. Feature requests. Changing requirements. Technical debt. Business leaders asking when something will be ready.
And somewhere in that environment, the security organization has another responsibility:
Keep application security risks in front of developers and demonstrate that appropriate security training has taken place.
That creates an interesting challenge when it comes to OWASP Top 10 training for developers.
Effective OWASP Top 10 training for experienced developers doesn’t have to replicate hands-on coding labs. It can serve a different purpose: reinforcing the broader patterns behind application security failures so developers recognize risk and know what questions to ask when they encounter something new.
Maybe the question isn’t:
How do we teach developers security?
Maybe it’s:
How do we give capable developers a meaningful pause to think about security?
Developer Security Training Has More Than One Job
There’s an understandable reaction to developer security training:
“I don’t want my developers clicking through a course. I want them writing code. Give them a lab. Make them find the vulnerability and fix it.”
That’s a good instinct.
Hands-on secure coding exercises, labs, code reviews, capture the flag exercises, and vulnerability remediation can be extremely valuable.
If your learning objective is to determine whether someone can identify and remediate a particular vulnerability in code, then asking them to work with code makes sense.
But is that the objective of every security learning experience?
Well… no.
Or perhaps more accurately: not always.
There is a difference between developing and demonstrating a technical skill and keeping important security risks present in someone’s thinking.
And there’s another practical problem with relying on labs alone:
We can’t teach every vulnerability a developer may encounter.
You Can’t Build a Lab for Everything
The OWASP Top 10 is ten categories, not ten individual vulnerabilities.
The OWASP Top 10: 2025 maps 248 Common Weakness Enumerations (CWEs) across those ten categories.
And that number helps illustrate why the categories themselves matter.
Technology doesn’t stand still.
New frameworks emerge. Dependencies change. Architectures evolve. APIs proliferate. New capabilities are introduced. AI is accelerating how software is created while simultaneously creating new questions about how vulnerabilities may be introduced, discovered, and exploited.
Trying to prepare developers by teaching every possible vulnerability individually becomes an endless game of catch-up.
A developer will eventually encounter something that wasn’t in a lab. It may not have been in the course. It may not even have been a known vulnerability when the training was created.
So alongside technical proficiency, there’s another capability worth reinforcing:
Pattern recognition.
Instead of only teaching this is the vulnerability and this is how you fix it, security training can encourage developers to think about the broader patterns behind security failures.
What assumptions are we making?
How could this functionality be misused?
Where are we placing trust?
What happens if that trust is misplaced?
What contributed to this incident?
Are we fixing the immediate symptom, or the underlying weakness that allowed it to happen?
Those questions are considerably more durable than any individual vulnerability example.
We can’t predict every vulnerability a developer will encounter.
But we can help keep the patterns in front of them so they recognize when it’s time to stop and ask the right questions.
That’s why hands-on labs and broader security awareness shouldn’t be treated as competing approaches.
Labs can help developers practice specific technical skills against known vulnerabilities. Broader risk-based learning can help them recognize patterns that may appear in situations they’ve never encountered before.
A mature application security program has room for both.
What Is OWASP Top 10 Training Actually Supposed to Accomplish?
This distinction becomes particularly important when we talk about the OWASP Top 10.
OWASP describes the Top 10 as a standard awareness document for developers and web application security, representing broad consensus about critical security risks to web applications.
OWASP’s own explanation of the 2025 edition also provides an interesting clue about the value of categories. Rather than reducing the Top 10 to ten individual CWEs, OWASP deliberately groups multiple weaknesses together under broader categories. Among its reasons, different weaknesses can occur under a common category, while individual CWEs may not apply equally across every programming language or framework.
That makes the categories useful for thinking beyond individual examples.
At the same time, OWASP recommends deeper secure coding practices and technical resources as part of a modern application security program.
In other words:
Awareness and technical proficiency are related, but they aren’t the same learning objective.
The OWASP Top 10 can help developers keep important categories of application risk visible. Hands-on technical training can go deeper into how particular vulnerabilities are identified, exploited, prevented, or remediated.
An effective application security program doesn’t have to choose between them.
Respect the Developer
This is where instructional design matters.
We started with a fairly simple assumption when thinking about our new OWASP Top 10: 2025 training:
Developers are smart. And they’d rather be coding.
One of the developers involved in the project put it more colorfully: we’re nerdy, we hate laborious training, and we’d rather get back to the work.
Fair enough.
So why design training that assumes the learner knows nothing?
If someone already understands a particular OWASP risk, don’t force them through a lengthy explanation before allowing them to do anything with it.
Give them the option of a quick refresher.
Need it? Take it.
Already comfortable with the concept? Keep going.
That small choice reflects a larger philosophy:
Respect what the learner already knows.
The objective isn’t to convince developers that security exists. It’s to create a deliberate interruption in an environment where dozens of other priorities are competing for their attention.
A short pause.
A situation.
A decision.
A consequence.
Something worth thinking about before moving on.
Scenario-Based OWASP Training: What Would You Do?
For some application security risks, the natural learning experience is a decision.
Consider A06:2025, Insecure Design.
Rather than beginning with a lengthy explanation, put the learner inside a system and give them a problem.
Here’s how the application behaves.
Here’s what the business wants.
Here’s a potential abuse case.
What would you do?
The learner makes a decision.
If that decision creates risk, show the consequence. Then explain what was overlooked and why another approach would have been stronger.
The point isn’t to prove that the developer can write the necessary code.
The point is to interrupt the automatic response long enough to ask:
Did you consider how this could be misused?
The fictional application may disappear when the course ends. The particular scenario may never happen exactly that way in the learner’s real environment.
But the underlying question travels with them.
Incident Review: What Happened and Why?
Not every OWASP risk lends itself naturally to a decision scenario.
Sometimes the better learning experience starts after something has already gone wrong.
Here’s the incident.
What happened?
What was the impact?
What factors contributed to it?
Which of those factors represent root causes?
Which corrective actions would actually reduce the likelihood of it happening again?
That’s closer to an incident review than a traditional course.
It asks the learner to examine evidence, categorize contributing factors, evaluate corrective actions, and connect what happened back to the underlying application security risk.
Again, we’re not asking the learner to prove they can code the remediation.
We’re asking them to think about the security problem and recognize the pattern behind the failure.
The next incident probably won’t look exactly like this one.
That’s why the interaction should fit the vulnerability and the learning objective. It shouldn’t simply vary for the sake of making training feel different.
Ten OWASP Risks Don’t Need Ten Identical Lessons
That became one of the guiding principles behind the new GLS OWASP Top 10: 2025 developer training experience.
Our Instructional Designer divided the ten OWASP risks between two types of missions based on which approach best suited the material.
Five use a Scenario Decision format.
The learner encounters a situation, evaluates possible responses, makes a decision, and sees the consequences.
Five use an Incident Review format.
The learner investigates an event, considers its impact, identifies contributing factors and root causes, evaluates corrective actions, and reviews the lessons learned.
The science fiction mission environment and gamification make the experience more engaging, but they’re not the instructional strategy by themselves.
They’re the wrapper.
The learning happens in the decisions, the analysis, the feedback, and the moments when the learner has to stop and think.
Throughout the experience, the fictional situations connect back to the relevant OWASP risk and underlying CWE references.
The entire ten mission experience takes approximately 90 minutes.
Will every developer celebrate when another required security course appears in their learning queue?
Probably not.
We’re realistic.
But perhaps “they’ll grumble less” is a more useful design objective than pretending anyone has been waiting excitedly for their next mandatory training assignment.
OWASP Training and Compliance Requirements
There is also an organizational reality we shouldn’t ignore.
Security leaders may need to demonstrate that developers have received appropriate security training.
For example, the OWASP Software Assurance Maturity Model (SAMM) calls for security awareness training for people involved in software development. Its guidance includes relevant content from the latest OWASP Top 10, repeatable training, acknowledgement or sign-off, regular content review and, in more mature programs, testing for understanding and more role-specific technical instruction.
OWASP SAMM also suggests considering innovative delivery approaches, including gamification, to help combat training desensitization.
The specific security and compliance requirements an organization must satisfy will depend on its regulatory environment, contractual obligations, policies, frameworks, and risk profile.
But the need to document training doesn’t have to be at odds with respecting developers’ time.
The mistake is assuming that because training must be documented, it must therefore feel like compliance training.
It doesn’t.
A security leader should be able to say:
Yes, our developers received training.
But hopefully they can also say:
And we chose an experience appropriate for what we were actually trying to accomplish.
Start With the Learning Objective
So, should developer security training include coding exercises?
Absolutely, when coding is the skill you’re trying to develop or evaluate.
But that isn’t every learning objective.
Sometimes you’re building technical proficiency. Sometimes you’re introducing a new concept. Sometimes you’re reinforcing something people already know.
And sometimes you’re developing something more durable than familiarity with a particular vulnerability:
The ability to recognize the broader patterns behind security failures and know what questions to ask when something new appears.
That’s increasingly important in an environment where technology and the vulnerabilities associated with it can change faster than any training curriculum.
Sometimes the most useful thing we can do is create a deliberate pause in a very busy developer’s day and ask:
What would you do here?
Or:
What went wrong here, and why?
The OWASP Top 10 helps keep critical application security risks visible.
Good OWASP Top 10 training for developers should help do the same. We can’t prepare developers for every vulnerability they’ll ever encounter, but we can reinforce patterns of risk that may help them recognize the next one.
So perhaps the better question isn’t whether developer security training contains enough coding exercises.
It’s:
What are we trying to accomplish, and does the learning experience actually match that objective?
That’s the question we tried to answer when we built the new Global Learning Systems OWASP Top 10: 2025 training experience.
If you’re responsible for application security, secure development, or developer training and you’re wrestling with the same question, we’d be happy to show you what we came up with.
