Secure Coding Training¶
Most vulnerabilities are introduced while code is being written. The cheapest place to prevent them is in the developer's head — which makes secure coding training one of the highest-leverage investments in a DevSecOps program. The goal is not to turn every developer into a security expert, but to give them the awareness, patterns, and reflexes to avoid the common, costly mistakes.
What to teach¶
Core web and application risk¶
- The OWASP Top 10 — owasp.org/www-project-top-ten — covers the ten most critical web application risks. Every developer writing server-side code should understand broken access control, injection, security misconfiguration, software supply chain failures, and insecure design.
- The relevant variant for your stack — OWASP API Top 10 for API developers, OWASP Mobile Top 10 for mobile engineers, OWASP Top 10 for LLM Applications and the OWASP Top 10 for Agentic Applications for teams building AI-powered features.
Security requirements and verification¶
- OWASP ASVS — owasp.org/www-project-application-security-verification-standard — a concrete catalog of what "secure" means for authentication, session management, validation, cryptography, APIs, and more (ASVS 5.0 has roughly 350 requirements across three levels). Use it as a training curriculum and as the definition-of-done for security requirements.
Defensive techniques¶
- OWASP Proactive Controls — owasp.org/www-project-proactive-controls — ten defensive techniques developers should apply in every application (2024 edition): implement access control, use cryptography to protect data, validate all input and handle exceptions, address security from the start, use secure-by-default configurations, keep components secure, secure digital identities, leverage browser security features, implement security logging and monitoring, and stop server-side request forgery.
Language- and framework-specific guidance¶
Generic security training does not stick as well as guidance tied to the developer's actual stack. Use the OWASP Cheat Sheet Series as a reference by topic and language:
| Language / Area | Key cheat sheets and pitfalls |
|---|---|
| Python | SQL Injection Prevention, avoiding pickle deserialization, safe subprocess usage, SSRF prevention |
| Java / Spring | Deserialization (avoiding ObjectInputStream), XXE Prevention, expression language injection |
| JavaScript / Node.js | Prototype pollution, ReDoS, path traversal in file operations, npm dependency confusion |
| Go | SQL injection in raw queries, TLS configuration, goroutine leaks in error paths |
| Terraform / Helm | Infrastructure as Code, hardcoded secrets, overly permissive IAM, unsafe default values |
| Authentication | Authentication Cheat Sheet, Session Management |
| Cryptography | Cryptographic Storage, TLS |
Secure code review¶
How to read code adversarially — spotting anti-patterns, data flow from untrusted input to dangerous sinks, missing authorization checks, and insecure defaults. Code review is where security knowledge directly translates into prevented vulnerabilities.
A minimal secure code review checklist:
- All inputs validated server-side (type, length, allowlist where feasible)
- Parameterized queries used for all database access; no string concatenation
- Authorization checked on every state-changing operation, not just at login
- Secrets not hardcoded; no API keys in source files or logs
- Error responses sanitized; no stack traces, internal paths, or query text exposed
- Cryptographic functions use current algorithms and library defaults (not custom implementations)
- Dependencies match the expected version; no unexpected additions
Integrating training into the developer lifecycle¶
Training is most effective when it meets developers where they already are, rather than pulling them out of their workflow.
Onboarding¶
Every new developer should complete security onboarding before or alongside technical onboarding:
- OWASP Top 10 awareness module (60–90 minutes, interactive)
- Language-specific cheat sheet review for their primary stack
- Introduction to internal tools (secrets scanner, SAST, pre-commit hooks) and how to interpret findings
- Introduction to the security champion for their team
Ongoing development¶
| Touchpoint | Delivery |
|---|---|
| IDE security plugin | Real-time feedback (Semgrep, Snyk, SonarQube for IDE) as code is typed |
| PR review | Automated comments linking findings to cheat sheet remediation guidance |
| Sprint planning | Security champion reviews relevant findings before estimation |
| Quarterly learning sprints | 2–4 hour focused lab on a current threat (e.g., LLM prompt injection, supply-chain attacks, poisoned CI workflows) |
| Incident retrospectives | Post-mortems that include secure-coding lessons from real vulnerabilities |
Defining a secure coding standard¶
Every organization should maintain a written secure coding standard — a living document that captures language-specific rules, approved libraries, and banned patterns. Minimum contents:
- Approved dependency sources — permitted registries, prohibited packages, lockfile requirements
- Authentication and session — required auth library, forbidden patterns (rolling your own JWT validation, storing tokens in localStorage)
- Input and output handling — validation libraries to use, encoding requirements per output context
- Database access — ORM or query builder required, raw query rules
- Secrets management — where secrets live (vault, environment variables), what is forbidden (committed plaintext, hardcoded strings)
- Cryptography — approved algorithms and key sizes; forbidden (MD5, SHA1 for security purposes, DES, ECB mode)
- Error handling — what to log, what to return in error responses
- Third-party code — review requirements before adoption, license check, security advisory monitoring
Link the standard from pull request templates so it is visible at review time.
What makes training stick¶
- Hands-on, not slideware — interactive labs and deliberately vulnerable apps beat passive video lectures. A developer who exploits a SQL injection in a lab will remember it; one who watches a slide about it will not.
- Just-in-time — surface a short, relevant lesson at the moment a developer hits a related finding in their IDE or PR review. Context and motivation are both highest at the point of discovery.
- Role-relevant — tailor content to the language, framework, and threat surface the developer works in.
- Continuous — short, frequent refreshers beat an annual compliance video. Aim for touchpoints at least quarterly.
Training delivery patterns¶
| Pattern | When it works best |
|---|---|
| Self-paced labs (platform-provided) | Baseline training, onboarding, async organizations |
| Just-in-time IDE nudges | Language-specific, integrated into daily workflow |
| Live workshops | Threat modeling, code review, high-engagement topics |
| CTF / bug bash events | Team building, gamification, surfacing advanced interest |
| Champion-led team sessions | Team-specific context, local tooling and codebase examples |
| Incident-driven retrospective labs | High relevance — recreating a real vulnerability builds lasting memory |
Reinforce in the AI era¶
With AI coding assistants generating a growing share of code, developers need to learn to:
- Review AI-generated code with the same scrutiny as hand-written code — AI assistants routinely produce SQL injection, path traversal, insecure deserialization, and other vulnerabilities.
- Recognize hallucinated dependencies — AI assistants sometimes suggest package names that do not exist, which attackers pre-register (a pattern called slopsquatting). Verify every suggested package.
- Apply secure-coding judgment to AI output — the developer is responsible for what they merge, regardless of who or what wrote it.
- Use AI as a teaching moment — when a scanner flags AI-generated code, treat it as a just-in-time training opportunity rather than just a fix-and-move-on task.
See IDE and AI-Assisted Development Security.
Measuring training effectiveness¶
Completion rates are a compliance metric, not a security metric. Track:
| Metric | What it measures |
|---|---|
| Security defect escape rate (pre-production vs production) | Whether training translates to fewer runtime vulnerabilities |
| Security findings per developer per quarter (trend) | Injection rate improvement over time |
| Mean time to remediate findings (MTTR) | Developer fluency with fixing security issues |
| % of PRs with at least one security finding | Coverage and discovery health |
| Developer satisfaction score for security tooling | Friction — high friction correlates with workarounds |
| Time-to-first-security-finding after onboarding | Leading indicator of onboarding effectiveness |
Maturity progression¶
| Level | Focus |
|---|---|
| Starting | OWASP Top 10 awareness; annual (or onboarding) completion; basic injection and XSS labs |
| Developing | Role-specific training tied to stack; just-in-time IDE integration; quarterly refreshers |
| Maturing | ASVS-aligned curriculum; escape rate tracked per team; training completion tied to sprint planning |
| Advanced | Developer-led threat modeling; champions deliver peer training; custom labs from internal incidents |
Tools1¶
Open-source¶
- OWASP crAPI — Completely Ridiculous API, a vulnerable API for practising OWASP API Top 10 attacks. Ideal for teams building or testing APIs.
- OWASP Juice Shop — Modern, intentionally insecure web application covering the OWASP Top 10 and beyond. Ideal for workshops and self-study; includes a Capture the Flag mode. Best for broad web security awareness.
- OWASP Security Knowledge Framework (SKF) — Provides security requirements, code examples, and labs mapped to ASVS. Supports integration into the development workflow. Best for teams wanting ASVS-aligned learning paths.
- OWASP Security Shepherd — Web and mobile security training platform with gamified, scored challenges. Well suited to classroom and internal competition formats.
- OWASP WebGoat — Deliberately insecure Java application with interactive lessons. Good for teams on JVM stacks; covers a wide set of Java-specific vulnerabilities.
Commercial¶
- Hack The Box — Hands-on hacking labs and training for both offensive and defensive skills. Best for engineers with security interest who want to go beyond awareness into technical depth.
- PortSwigger Web Security Academy — Free, self-paced web security labs and learning paths from the makers of Burp Suite. Best for developers who want deep, practical web vulnerability knowledge at no cost.
- Secure Code Warrior — Gamified, language-specific secure-coding training integrated into the developer workflow; supports tournament-style team challenges. Best for enterprise-scale developer programs with manager dashboards.
- SecureFlag — Hands-on secure-coding training in real, runnable environments across 30+ languages and frameworks. Best for breadth of language support.
- Snyk Learn — Free and integrated secure coding lessons mapped to real CVEs and language-specific vulnerabilities. Best for just-in-time learning tied to actual Snyk findings.
- TryHackMe — Guided, browser-based labs and learning paths, including web and application security rooms. Best for beginners who need a structured on-ramp.
Links¶
-
Listed in alphabetical order. ↩