Implementing developer security training program

Having a curriculum and assessment plan is not enough. The real challenge is implementation: getting leadership buy-in, convincing skeptical developers, rolling out training at scale, and building lasting culture change.

This article provides a practical, step-by-step implementation roadmap. Follow these phases in order — each builds on the previous. By the end, you'll have a functioning developer security program with measurable results.

Three-part series

This is Part 3 of the developer security training series:

1. Curriculum and resources — what to teach
2. Assessment and competency mapping — how to evaluate skills
3. Implementation guide (this article) — how to roll out the program

Step-by-step implementation guide

Phase 1: Get buy-in and understand the landscape (Week 1-2)

Step 1.1: Kickoff meeting with leadership

Before doing anything else, get explicit support from management. Without it, developers will treat security training as optional.

Meeting attendees:

• CTO/VP Engineering
• Team leads / Engineering managers
• You (Security Champion)

Agenda:

## Developer Security Training - Kickoff Meeting

### 1. Why we need this (10 min)
- Industry statistics on developer-caused vulnerabilities
- Cost of fixing bugs in production vs development
- Recent incidents (company-specific or industry)

### 2. Proposed program overview (15 min)
- Competency framework
- Assessment approach
- Training resources
- Time investment required

### 3. What we need from leadership (10 min)
- Mandate for mandatory participation
- Protected time for training (X hours/quarter)
- Budget (if using paid platforms)
- Support for security culture initiatives

### 4. Timeline and next steps (10 min)
- Technology inventory (1 week)
- Assessment creation (2 weeks)
- Initial assessment (2 weeks)
- Training rollout (ongoing)

### 5. Questions and concerns (15 min)

Key asks:

1. Time allocation — developers need dedicated hours, not "do it in your spare time"
2. Mandatory participation — leadership must communicate this is required
3. Budget (optional) — for paid training platforms if needed
4. Patience — culture change takes 6-12 months

Success criteria: Leave with written approval (email follow-up) confirming:

• Program is approved
• Time allocation is defined (e.g., 4 hours/quarter)
• Leadership will announce the program

Step 1.2: Inventory your technology stack

You can't create relevant training without knowing what technologies your teams use. Different stacks have different security concerns.

Create technology inventory spreadsheet:

Team	Languages	Frameworks	Databases	Cloud	APIs	Mobile	Other
Backend	Python, Go	Django, FastAPI	PostgreSQL, Redis	AWS	REST, GraphQL	-	Celery, RabbitMQ
Frontend	TypeScript	React, Next.js	-	Vercel	REST	-	-
Mobile	Kotlin, Swift	Android SDK, iOS SDK	SQLite	Firebase	REST	Android, iOS	-
Platform	Python, Bash	Terraform, Ansible	-	AWS, GCP	-	-	Docker, K8s
Data	Python, SQL	Spark, Airflow	Snowflake, PostgreSQL	AWS	-	-	-

How to collect:

1. Ask team leads directly
2. Review package.json, requirements.txt, go.mod files
3. Check CI/CD configurations
4. Review infrastructure-as-code

Step 1.3: Map technologies to security topics

Not every developer needs every topic. A frontend developer doesn't need deep SQL injection training if they never write SQL.

Security topic matrix by role:

Security topic	Backend	Frontend	Mobile	DevOps	Data
Input validation	●●●	●●○	●●●	●○○	●●○
SQL injection	●●●	○○○	●●○	○○○	●●●
NoSQL injection	●●●	○○○	●●○	○○○	●●○
XSS	●●○	●●●	●○○	○○○	○○○
CSRF	●●●	●●○	○○○	○○○	○○○
Authentication	●●●	●●○	●●●	●●○	●○○
Authorization/IDOR	●●●	●○○	●●●	●○○	●●○
Cryptography	●●○	●○○	●●○	●●○	●●○
Secrets management	●●○	●○○	●●○	●●●	●●○
Container security	●○○	○○○	○○○	●●●	●○○
Cloud security	●○○	○○○	○○○	●●●	●●○
API security	●●●	●●○	●●●	○○○	○○○
Mobile security	○○○	○○○	●●●	○○○	○○○

Legend: ●●● = Essential | ●●○ = Important | ●○○ = Awareness | ○○○ = Not needed

Phase 2: Create assessment materials (Week 3-4)

Step 2.1: Choose assessment platform

Platform	Pros	Cons	Best for
Google Forms	Free, easy	No code execution	Small teams, quick start
Self-hosted CTFd	Gamified, flexible	Setup required	Engineering-focused orgs
Secure Code Warrior	Comprehensive	Expensive	Enterprise with budget
Custom quiz app	Full control	Development effort	Specific needs

For small companies: Start with Google Forms + code samples in images/text. Upgrade to paid platform if program succeeds.

Step 2.2: Create questions for each role

Use the question templates from Part 2 (Assessment and competency mapping). Create questions tailored to your technology stack.

Per-role question distribution:

## Backend Developer Assessment (40 questions)

Core (all backend devs):
- OWASP Top 10 concepts: 10 questions
- SQL/NoSQL injection: 5 questions  
- Authentication/session: 5 questions
- Authorization/IDOR: 5 questions
- API security: 5 questions

Stack-specific (choose based on technology):
- Python security: 5 questions (if using Python)
- Node.js security: 5 questions (if using Node)
- Java security: 5 questions (if using Java)
- Go security: 5 questions (if using Go)

Advanced (for senior developers):
- Cryptography: 3 questions
- Threat modeling: 2 questions

Step 2.3: Set up assessment delivery

Logistics checklist:

• Create assessment in chosen platform
• Set time limit (45-60 minutes)
• Enable answer randomization (prevents copying)
• Prepare instructions for participants
• Schedule assessment window (1-2 weeks)
• Prepare reminders for non-completers
• Create spreadsheet for results analysis

Phase 3: Conduct initial assessment (Week 5-6)

Step 3.1: Communicate with developers

Communication template:

Subject: Developer Security Assessment - Action Required by [DATE]

Hi team,

As part of our security improvement initiative (announced by [CTO/MANAGER]), 
we're running a baseline security assessment for all developers.

**What:** 45-minute security knowledge assessment
**Why:** Identify training priorities and build personalized learning paths
**When:** Complete by [DATE]
**Where:** [LINK]

This is NOT a performance evaluation. Results will be used only to:
1. Identify team-wide training needs
2. Create personalized learning recommendations
3. Track our improvement over time

Your individual scores are confidential. We'll share aggregate team results.

Questions? Reply to this email or ask in #security-champions.

Thanks,
[Your name]

Step 3.2: Run the assessment

During assessment window:

• Send reminder at 50% of window
• Send final reminder 2 days before deadline
• Track completion rates
• Answer questions promptly

Common issues and solutions:

Issue	Solution
"I don't have time"	Remind of leadership mandate, offer flexible window
"The questions are unfair"	Accept feedback, adjust for next assessment
"I can't access the form"	Provide direct link, check permissions
Technical issues	Have backup plan (PDF version)

Step 3.3: Analyze results

Create results analysis spreadsheet:

Developer	Role	Core Score	Stack Score	Advanced Score	Overall	Level
Alice	Backend	75%	80%	40%	72%	L2
Bob	Frontend	65%	70%	N/A	67%	L1
Carol	DevOps	60%	85%	50%	68%	L1
...	...	...	...	...	...	...
Team Avg		67%	75%	45%	68%

Identify patterns:

• Which topics have lowest scores team-wide?
• Which roles struggle most?
• Are there individual outliers who need extra support?

Step 3.4: Create team heatmap

Visualize competency across the team:

Name	SQLi	XSS	Auth	IDOR	Crypto	API	Overall
Alice	✓✓	✓✓	✓✓	✓	—	✓✓	L2
Bob	✓	✓✓	✓	✓	—	✓	L1
Carol	✓✓	—	✓✓	✓✓	✓✓	✓	L1
David	✓✓	✓✓	✓✓	✓✓	✓	✓✓	L2
Priority	OK	GAP	OK	OK	GAP	OK

Step 3.5: Identify priority training areas

Based on results, prioritize training:

## Q1 Training Priorities

### Team-wide gaps (address first)
1. **Cryptography** - 45% average score
   - Action: Schedule 2-hour workshop
   - Resources: OWASP Cryptography Cheat Sheet

2. **XSS Prevention** - 55% average score
   - Action: Assign PortSwigger XSS labs
   - Resources: React security best practices

### Individual gaps
| Developer | Gap area | Recommended training |
|-----------|----------|---------------------|
| Alice | IDOR, Crypto | Auth/Authz module, Crypto workshop |
| Bob | Auth, SQLi | WebGoat auth labs, SQLi course |
| Carol | XSS | PortSwigger XSS labs |

Phase 4: Deploy targeted training (Week 7-12)

Step 4.1: Create individual training plans

Template for individual plan:

## Security Training Plan: [Developer Name]

**Current level:** L1 (Aware)
**Target level:** L2 (Practitioner)
**Timeline:** 8 weeks

### Gap areas:
1. SQL Injection (scored 50%)
2. Authentication (scored 55%)

### Training schedule:

**Week 1-2: SQL Injection**
- Complete: PortSwigger SQL injection labs (4 hours)
- Read: OWASP SQL Injection Prevention Cheat Sheet
- Practice: Fix vulnerabilities in WebGoat

**Week 3-4: Authentication & Session Management**
- Complete: PortSwigger Authentication labs (4 hours)
- Read: OWASP Authentication Cheat Sheet
- Review: Our codebase's auth implementation

**Week 5-6: Input Validation**
- Complete: OWASP Input Validation module
- Practice: Write input validation for 3 APIs in our codebase
- Code review: Review PRs with security focus

**Week 7-8: Assessment and consolidation**
- Retake assessment
- Mentor session with senior developer
- Apply learning to current project

### Time allocation: 4 hours/week

Step 4.2: Group training for common gaps

If many developers share the same gap, run group sessions:

Group training session template:

## Session: SQL Injection Prevention
**Duration:** 2 hours
**Attendees:** Developers scoring under 70% on SQLi questions

### Agenda:

**0:00-0:15 - Introduction**
- Why we're here (assessment results)
- What we'll cover
- Why this matters for our product

**0:15-0:45 - Concept review**
- How SQL injection works (demo with DVWA)
- Real-world examples and impacts
- Our codebase examples (anonymized)

**0:45-1:15 - Prevention techniques**
- Parameterized queries
- ORM usage
- Input validation
- Prepared statements
- Least privilege for database accounts

**1:15-1:45 - Hands-on practice**
- Fix vulnerable code samples
- Review actual PRs for SQL injection risks

**1:45-2:00 - Q&A and resources**
- Additional learning resources
- How to get help
- Next steps

### Post-session:
- Recording shared for those who couldn't attend
- Practice exercises assigned
- Follow-up quiz in 2 weeks

Step 4.3: Track training completion

Training tracker:

Developer	Required training	Status	Completion date	Verified
Alice	Crypto course	Completed	2024-02-15	✓
Alice	TM workshop	In progress	-	-
Bob	SQLi labs	Completed	2024-02-10	✓
Bob	Auth labs	Not started	-	-
Carol	XSS deep-dive	Completed	2024-02-12	✓

Phase 5: Reassess and iterate (Ongoing)

Step 5.1: Schedule follow-up assessment

Timeline:

• Initial assessment: Week 5-6
• First follow-up: 8-12 weeks later
• Ongoing: Quarterly

Follow-up assessment should:

• Use different questions (to test learning, not memorization)
• Focus on areas where training was provided
• Include some new questions for continuous improvement

Step 5.2: Measure improvement

Metrics to track:

Metric	Baseline	Target	Current
Avg L1 score	72%	90%	-
Avg L2 score	55%	75%	-
Training completion	0%	100%	-
Security bugs per release	8	4	-
Time to fix security bugs	5 days	2 days	-

Step 5.3: Adjust program based on results

After each assessment cycle:

1. Identify remaining gaps
2. Update training priorities
3. Add new topics as needed
4. Remove topics that are now well-understood
5. Recognize high performers

Phase 6: Create onboarding materials (Month 3+)

Step 6.1: Security onboarding for new developers

Every new hire should complete security fundamentals in first month.

Onboarding security curriculum:

Week	Topic	Format	Time
1	Security fundamentals	Self-paced reading	2 hours
1	Company security policies	Required reading	1 hour
2	OWASP Top 10	Self-paced course	4 hours
2	Role-specific training	Assigned modules	4 hours
3	Initial assessment	Quiz	1 hour
4	Mentor session	1:1 with senior dev	1 hour

Step 6.2: Create security onboarding packet

# Security Onboarding Packet

Welcome to [Company]! Security is everyone's responsibility. 
Here's what you need to know in your first month.

## Required reading (Week 1)
- [ ] Company Security Policy (link)
- [ ] Secure Coding Guidelines (link)
- [ ] How we handle secrets (link)

## Required training (Week 2)
- [ ] OWASP Top 10 course (link)
- [ ] [Role-specific] security module (link)

## Assessment (Week 3)
- [ ] Complete security assessment (link)
- [ ] Review results with your mentor

## Getting help
- Slack: #security-questions
- Security Champion: [Name]
- Security office hours: Thursdays 3-4pm

## Your security checklist
Before your first commit:
- [ ] Read secure coding guidelines
- [ ] Understand our auth system
- [ ] Know how to handle secrets
- [ ] Complete security assessment

Step 6.3: Automate onboarding tracking

Add security training to onboarding checklist in your HR system or use a simple spreadsheet:

New hire	Start date	Reading	Training	Assessment	Mentor session
Eve	2024-03-01	✓	✓	78%	Scheduled
Frank	2024-03-15	✓	In progress	-	-

Timeline summary

Phase	Timeline	Activities
Foundation	Weeks 1–2	Leadership buy-in, technology inventory
Preparation	Weeks 3–4	Create assessment materials
Assessment	Weeks 5–6	Run initial assessment
Training	Weeks 7–12	Deploy training (ongoing)
Iteration	Week 13+	Reassess, iterate, integrate into onboarding
Steady state	Ongoing	Quarterly assessments, culture building

Checklist: Is your program ready?

Before launching, verify:

• Leadership has approved the program in writing
• Time allocation is defined and communicated
• Technology inventory is complete
• Role-to-topic mapping is done
• Assessment materials are ready
• Training resources are identified
• Communication plan is ready
• Tracking spreadsheet/system is set up
• At least one Security Champion is trained
• Success metrics are defined

Creating a security-minded culture

Technical training isn't enough. You need cultural practices that reinforce security.

Security code review culture

Make security part of every code review:

Security checklist for PRs:

## Security Review Checklist

Before approving, verify:

### Authentication & Authorization
- [ ] Auth required for all sensitive endpoints
- [ ] Authorization checked for resource access
- [ ] No hardcoded credentials or secrets

### Input Handling
- [ ] All inputs validated and sanitized
- [ ] Parameterized queries for database access
- [ ] Output encoding applied

### Data Protection
- [ ] Sensitive data identified and protected
- [ ] No sensitive data in logs
- [ ] Proper error handling (no stack traces to users)

### Dependencies
- [ ] New dependencies reviewed for security
- [ ] No known vulnerabilities in dependencies

### If applies:
- [ ] File uploads validated and secured
- [ ] Crypto uses approved libraries/algorithms
- [ ] Rate limiting on sensitive endpoints

Assigning security reviewers:

For high-risk changes, require review from someone with security expertise:

# CODEOWNERS example
# Security-sensitive paths require security-trained reviewer

/auth/** @security-champions
/api/payments/** @security-champions
/crypto/** @security-champions
*.pem @security-champions
*.key @security-champions

Security office hours

Regular time when developers can ask security questions:

Format:

• Weekly 1-hour slot
• Security Champion or security team available
• Open to any question
• No judgment zone

Benefits:

• Lowers barrier to asking security questions
• Identifies common issues (training topics)
• Builds relationships
• Catches issues early

Security retrospectives

Add security to sprint retrospectives:

Questions to ask:

• Did we ship any security improvements this sprint?
• Did we find any security issues? How?
• Were there security questions we couldn't answer?
• What security debt are we carrying?

Blameless security culture

When vulnerabilities are found:

• Focus on systems, not individuals
• Ask "how did this pass review?" not "who wrote this?"
• Improve processes, not punish people
• Thank reporters and fixers

Bad: "Who approved this PR with SQL injection?"

Good: "How can we improve our review process to catch SQL injection before it reaches production?"

Actions: add SQL injection to the code review checklist · enable Semgrep rule for SQLi detection · training refresher on parameterized queries

Gamification for developers

Make security engaging:

Activity	Points	Notes
Complete security training	100	Per module
Find vulnerability in code review	200	Before production
Report security concern	50	Encourages reporting
Fix security issue	150	Faster = more points
Pass security quiz	100	Monthly
Participate in CTF	200	Participation, bonus for placing
Mentor another developer	150	On security topic

Recognition:

• Monthly security MVP
• Security Champion badge
• Leaderboard (optional — some teams find competitive)
• Conference attendance for top performers

Communicating with developers: strategies and objection handling

The biggest challenge isn't creating training content — it's getting developers to engage with it. This section provides strategies for effective communication and handling the objections you'll inevitably face.

Understanding developer psychology

Developers are:

1. Pragmatic — They want to know "will this help me do my job?"
2. Skeptical — They've seen many corporate initiatives fail
3. Time-constrained — Every hour on training is an hour not shipping
4. Proud of their work — They don't want to hear their code is insecure
5. Autonomous — They resist being told what to do

Communication principles

1. Lead with respect, not fear

BAD:  "Your code has vulnerabilities that could get us hacked."
GOOD: "I'd like to share some patterns that could make this more resilient."

BAD:  "You need to take this security training."
GOOD: "There's some really interesting content on attack techniques — 
      thought you might find it useful."

BAD:  "Security found issues in your PR."
GOOD: "I noticed something that could be strengthened — mind if I explain?"

2. Speak their language

Developers respond to:

• Code examples, not bullet points
• Technical accuracy, not hand-waving
• Real attacks, not hypothetical risks
• Efficiency improvements, not bureaucracy

BAD: "SQL injection is when malicious actors inject code into your queries."

GOOD: "See this query? 
    cursor.execute(f'SELECT * FROM users WHERE id = {user_id}')
    
    If user_id is '1 OR 1=1', you've just returned every user.
    Here's the fix:
    cursor.execute('SELECT * FROM users WHERE id = %s', (user_id,))"

3. Make it about their growth, not compliance

BAD: "Company policy requires annual security training."

GOOD: "Security skills are in huge demand — this could be a career 
      differentiator for you. Companies like Google require security 
      expertise for senior roles."

4. Acknowledge the friction honestly

BAD: "This won't take much time."

GOOD: "I know this adds to your workload. Let me explain why we think 
      it's worth the investment, and I'm open to feedback on how to 
      make it less painful."

Handling common objections

Objection: "We don't need this — we haven't been hacked"

What they're really saying: "I don't see evidence of a problem."

Response strategy: Make the invisible visible.

**Response:**

"That's actually what most companies say before they get breached. 
The thing is, you often don't know you've been compromised until much later.

Here's some data:
- Average time to detect a breach is 194 days (IBM 2024)
- 43% of web applications have high-severity vulnerabilities (Veracode)
- We've had [X] security findings from our SAST tools this quarter

Let me show you what our attack surface looks like from outside..."

**Action:** Run a quick vulnerability scan or Shodan search and show results.

Objection: "Our frameworks handle security for us"

What they're really saying: "I trust the tools I use."

Response strategy: Show framework limitations without dismissing their expertise.

**Response:**

"You're right that modern frameworks have great built-in protections. 
Django escapes output by default, React sanitizes JSX, ORMs prevent 
most SQL injection.

But here are some gaps frameworks don't cover:

1. **Business logic flaws** — No framework prevents IDOR:
   /api/users/123/orders  # Can user 456 access this?

2. **Configuration mistakes:**
   DEBUG = True  # In production
   ALLOWED_HOSTS = ['*']

3. **Framework bypasses:**
   # Django: safe by default
   {{ user_input }}
   
   # But developers add |safe when they need HTML
   {{ user_input|safe }}  # Now vulnerable

4. **Authentication logic** — Frameworks provide primitives, 
   not complete solutions. Password reset flows, session handling, 
   MFA — those are on us.

I'm not saying our code is bad. I'm saying frameworks are layer one, 
not the complete solution."

**Action:** Find a real example from your codebase where framework 
defaults were overridden.

Objection: "We don't have time for this"

What they're really saying: "This isn't a priority vs. my current work."

Response strategy: Frame time investment vs. time cost of issues.

**Response:**

"I hear you — everyone's bandwidth is maxed. Let me share some numbers:

Time investment:
- Initial assessment: 45 minutes
- Quarterly training: 2-4 hours
- Total: ~12 hours per year

Time cost of security issues:
- Average CVE fix in production: 16 hours
- Security incident response: 40+ hours  
- Post-breach remediation: weeks to months

Last quarter, we spent [X] hours fixing security bugs that could 
have been prevented. This training is designed to reduce that.

Also, leadership has approved [X] hours of protected time for this. 
It's not on top of your sprint work — it's part of it."

**Alternative approach:** 
"What if we start with just the most critical topics for your role? 
We've prioritized to make this as efficient as possible."

Objection: "This training is too basic / I already know this"

What they're really saying: "Don't waste my time with fundamentals."

Response strategy: Validate their expertise, offer appropriate challenge.

**Response:**

"I appreciate that — you clearly have security knowledge. Let's 
make sure the training matches your level.

Option 1: Take the assessment first. If you score at L2 or higher, 
we'll skip the basics and focus on advanced topics like threat 
modeling, security architecture, and mentoring others.

Option 2: Instead of taking the training, would you be interested 
in helping create or review the materials? We need people who 
understand both development and security.

Option 3: The advanced CTF challenges are designed for people 
like you. Want to try those instead?"

**Key:** Give them an out that still contributes to the program.

Objection: "Security slows us down"

What they're really saying: "I've had bad experiences with security blocking my work."

Response strategy: Acknowledge past friction, position this differently.

**Response:**

"I've heard that frustration before, and honestly, sometimes security 
processes have been implemented poorly.

Here's what's different about this program:

1. **It's developer-led.** I'm an engineer, not a security auditor. 
   I understand shipping pressure.

2. **It's about enabling, not blocking.** The goal is to help you 
   ship faster by catching issues before they become blockers.

3. **It's practical.** No 50-page policies. Real code, real 
   vulnerabilities, real fixes.

4. **It integrates with your workflow.** Security tests in CI, 
   not manual reviews that hold up deploys.

Think of it like testing. Good test coverage doesn't slow you down — 
it speeds you up by catching bugs early. Security is the same."

**Follow-up:** Ask about specific past friction points and address them.

Objection: "Can't we just buy a tool for this?"

What they're really saying: "Automate the problem away."

Response strategy: Show the limits of automation.

**Response:**

"We should absolutely use tools — and we do. We've got [SAST/Snyk/etc] 
in our pipeline.

But here's what tools can't do:

1. **Business logic vulnerabilities** — Tools can't know that user A 
   shouldn't access user B's data. Only developers understand the 
   business rules.

2. **False positives** — Someone needs to know if a finding is real 
   or not. Last month we had [X] findings — a developer who 
   understands security can triage in minutes vs. hours.

3. **Secure design** — Tools find bugs in existing code. They can't 
   help you design features securely from the start.

4. **New vulnerability types** — Tools lag behind attackers. The 
   team that found Log4Shell did it through understanding, not 
   scanning.

Tools are force multipliers, but they multiply human knowledge. 
Without the knowledge, you're just multiplying by zero."

Objection: "This is the security team's job"

What they're really saying: "That's not my responsibility."

Response strategy: Clarify shared responsibility without being preachy.

**Response:**

"If we had a 10-person security team, they'd still need developers 
who understand security. Here's why:

1. **Scale** — We have [X] developers making [Y] commits per month. 
   No security team can review all of that. Developers are the 
   first line of defense.

2. **Context** — You understand the code better than anyone. 
   Security specialists might miss that edge case you know exists.

3. **Speed** — Waiting for security review slows everything down. 
   If you can self-review, you ship faster.

4. **Quality** — Writing secure code is like writing performant 
   code or maintainable code. It's a craftsmanship thing.

I'm not asking you to become a security expert. I'm asking you to 
add security to your existing expertise. Like how you're not a 
DBA but you understand database performance."

Objection: "I'll just fix it if something breaks"

What they're really saying: "Reactive is good enough."

Response strategy: Show the cost asymmetry.

**Response:**

"That works for bugs, but security is different. When something 
'breaks' in security, it means:

- Customer data is already leaked
- Attacker has access and is covering tracks
- We're in incident response mode, not bug fix mode
- Legal and PR are involved
- Regulatory penalties may apply

The fix-it-when-it-breaks approach costs 6x more for bugs, but 
for security issues, it can be company-ending.

Remember [recent breach in news]? They probably had the same 
attitude until it cost them [$ amount / reputation].

Prevention costs hours. Remediation costs weeks. Recovery from 
breach costs months or years — if you survive."

Dealing with persistent resistance

Sometimes, despite your best efforts, some developers remain resistant. Here's how to handle it:

Document the conversation

Keep notes on objections raised and your responses. This helps:

• Track patterns across the team
• Escalate to management if needed
• Improve your approach over time

Involve their manager

If someone consistently refuses mandatory training:

**To manager:**

"Hi [Manager], I wanted to flag that [Developer] hasn't completed 
the security assessment/training. I've discussed the importance 
with them on [dates] and addressed their concerns about [X, Y, Z].

This is mandatory per [CTO/policy], and I wanted to make you 
aware before I follow up again. Is there context I'm missing, 
or anything I can do differently?"

Find allies first

Don't try to convert everyone at once. Find developers who are:

• Naturally interested in security
• Influential on their team
• Respected by skeptics

Get them on board first. They'll help convince others.

Let results speak

After initial skeptics see:

• Vulnerabilities caught before production
• CTF challenges that are actually fun
• Colleagues gaining valuable skills

They often come around. Play the long game.

Accept that some won't engage

Not everyone will become a security enthusiast. That's okay. The goal is:

• Baseline competency (L1) for everyone
• Enthusiasts (L2+) who drive the culture
• Tools and processes that catch gaps

Building advocates, not just compliance

The goal isn't reluctant compliance — it's genuine engagement. Here's how to build advocates:

Make it interesting

**Instead of:** "Complete these training modules by Friday"

**Try:**
- "I found this fascinating write-up on how [company] got breached"
- "There's a bug bounty on our staging environment this month"
- "Check out this CTF challenge — bet you can't solve it in 30 min"

Give them wins

- Let developers present security topics they've learned
- Celebrate when they find vulnerabilities in code review
- Create "security champion" badges or recognition
- Give credit in public channels when they improve security

Connect to their interests

- Performance-focused? Security bugs can cause DoS
- Architecture-focused? Discuss secure design patterns
- Open-source contributor? OWASP needs help
- Career-focused? Security skills are differentiators

Make it a community

- Slack channel for security discussions (not just alerts)
- Monthly security brown-bags with interesting topics
- CTF teams that compete together
- Security office hours where questions are welcome

Sample conversation scripts

Approaching a skeptical senior developer

You: "Hey [Name], got a few minutes? I'm working on the security 
training program and wanted your input."

Dev: "Sure, though I have to say I'm not sure we need more training."

You: "I get that — you've probably seen your share of checkbox 
training. This is meant to be different. Can I ask what's been 
your experience with security training before?"

Dev: [Shares experience]

You: "Makes sense. What we're building is more hands-on — actual 
code, actual vulnerabilities. The goal is to make it relevant to 
what you do daily.

Actually, given your experience, I was wondering if you'd be 
interested in helping shape the content for senior developers? 
We need someone who can call BS on anything too basic or theoretical."

Dev: "I could take a look, I guess."

You: "Great. Here's what we have so far — tell me what you think is 
useful vs. waste of time. Your honest feedback would really help."

Responding to a frustrated developer post-assessment

Dev: "I got flagged for 'low score' on authentication, but I've 
been building auth systems for years. These questions are ridiculous."

You: "That's frustrating — let me look at your responses... 

Ah, I see the disconnect. Question 12 was about JWT algorithm 
confusion attacks. That's a pretty specific edge case — not 
everyone would know that.

The assessment is meant to identify gaps, not judge overall 
competence. You clearly have strong auth fundamentals. Would you 
rather skip the basics and just cover the advanced edge cases 
like algorithm confusion?

Also, if you think the question was poorly written, I'd value 
your feedback. We're iterating on these."

When someone says "this is a waste of time" publicly

Dev (in Slack): "Why are we spending time on security training 
when we have actual features to ship?"

You (reply in thread): "Fair question. The short answer: we 
spent [X hours] fixing security bugs last quarter that could have 
been prevented. The training is designed to reduce that.

The longer answer: leadership approved [Y hours] of protected time 
specifically for this. It's not taking from feature work — it's 
prioritized alongside it.

I'm also open to feedback on how to make it more useful. What 
would make this worth your time?"

[Continue conversation in DM if needed]

Tracking sentiment and adjusting

Create a simple way to track developer sentiment:

Post-training survey (anonymous):

1. Was this training relevant to your work? (1-5)
2. Did you learn something new? (1-5)
3. Was the time investment reasonable? (1-5)
4. Would you recommend this to a colleague? (1-5)
5. What would make this training better? (free text)
6. What topics would you like to see covered? (free text)

Track over time:

• Average scores per question
• Common themes in free text
• Changes after you adjust based on feedback

Act on feedback visibly:

"Based on your feedback from Q1:
- We shortened Module 2 from 2 hours to 45 minutes
- We added more code examples, fewer slides  
- We created a 'skip to advanced' path for experienced developers

Keep the feedback coming — this program is for you."

Common mistakes to avoid

1. Launching without leadership support — Program dies when priorities shift
2. Making it optional — Only enthusiasts participate
3. One-size-fits-all training — Wastes everyone's time
4. Theory without practice — Knowledge doesn't stick
5. Punishing low scores — Discourages honest assessment
6. Not measuring results — Can't prove value
7. Ignoring developer feedback — Breeds resentment
8. Moving too fast — Culture change takes time
9. Fighting every battle — Some resistance is okay
10. Forgetting maintenance — Skills decay without practice

Workshop: implementing developer security program

Part 1: Assess current state

1. Survey team security knowledge:

   • Distribute basic security quiz
   • Review current training (if any)
   • Identify team's biggest knowledge gaps

2. Analyze past vulnerabilities:

   • What types of issues have been found?
   • Were they in code review, testing, or production?
   • What patterns exist?

Part 2: Design curriculum

1. Map competencies:

   • Create competency framework for your team
   • Assess current levels
   • Identify target levels

2. Select training resources:

   • Choose courses for each topic
   • Schedule time for training
   • Set up hands-on environments

3. Create training calendar:

   • Monthly security topic
   • Quarterly assessment
   • Annual CTF

Part 3: Implement practices

1. Update code review process:

   • Add security checklist
   • Designate security reviewers
   • Set up CODEOWNERS for sensitive paths

2. Set up security testing:

   • SAST in CI/CD
   • Security test examples
   • QA security checklist

3. Launch cultural initiatives:

   • Security office hours
   • Slack channel for security questions
   • Recognition program

Artifacts to produce

1. Security competency framework — levels and areas for your team
2. Individual competency maps — assessment for each developer
3. Training curriculum — topics, resources, schedule
4. Code review security checklist — integrated into PR process
5. Assessment materials — quiz, code review exercise
6. Security office hours schedule — recurring calendar invite

Self-check questions

1. What are the six phases of implementing a developer security program?
2. Why is leadership buy-in essential before launching?
3. How do you handle a developer who says "our frameworks handle security"?
4. What's the difference between teaching security and building security culture?
5. How often should developers be reassessed?
6. What metrics demonstrate that the program is working?
7. Why is blameless culture important for security?
8. How do you deal with persistent resistance to training?
9. What should be included in security onboarding for new developers?
10. What's the purpose of security office hours?

How to explain this to leadership

Connect to business risk: "Our developers write the code that protects customer data. Training them to write secure code prevents breaches more effectively than any security tool."

Show the math: "Fixing a vulnerability in development costs 6x less than in production. A $10K investment in developer training could prevent a $4M breach."

Address concerns:

• "Time investment is minimal — a few hours per quarter"
• "Most resources are free (OWASP, PortSwigger)"
• "We can measure improvement with assessments"

Present the plan: "I'm proposing structured security training for all developers. We'll assess skills, provide targeted training, and track improvement. Within 6 months, every developer will meet baseline security competency."

Competitive angle: "Companies like Google, Microsoft, and Amazon require security training for all engineers. This is industry standard for any company handling customer data."

Conclusion

The biggest obstacle to developer security training isn't technical — it's getting consistent time allocation and keeping momentum past the first quarter. Get those commitments in writing before you start.

What's next

Next: security policies and procedures — writing policies people will actually read and follow.