Building a Security Champions Program

What a security champions program is (and isn’t)

A security champions program places one trained developer in each engineering team to act as the local security contact. Champions are not security engineers. They are developers who take on an additional, part-time responsibility: helping their team write safer code and respond to vulnerability findings faster.

The “champion” title can mislead. It does not mean this person reviews every pull request for security issues or owns the team’s entire vulnerability backlog. It means they are the first person to consult when a security question comes up, the one who reviews high-risk changes, and the bridge between their team and the central AppSec group.

What a champion is not: a replacement for a security team, a dedicated auditor, or the person who gets blamed when a vulnerability reaches production. Programs that position champions as scapegoats fail within months.

Why you need one

The math is simple. Most security teams are outnumbered 50:1 or worse. If your company has 3 security engineers and 200 developers, there is no way those 3 people can review every pull request, triage every scanner finding, and answer every question about secure authentication patterns.

A 2024 BSIMM study found that organizations with active champion programs fixed vulnerabilities 40% faster than those without. When the person who introduced a flaw is sitting next to someone who can explain the fix, remediation happens in hours instead of weeks.

Champions also reduce noise for the central security team. Instead of fielding the same questions about input validation or JWT handling from every team, the security team trains 10-15 champions who then handle those questions locally. This frees up the security team to focus on architecture reviews, threat modeling, and tooling.

Without champions, security knowledge concentrates in a small group that becomes a bottleneck. Feature releases wait for security reviews. Developers bypass the review process because the queue is too long. Vulnerabilities slip through because nobody on the team noticed the issue in the diff.

Selecting champions

Pick developers who are genuinely curious about security. Seniority matters less than interest. A mid-level developer who reads about vulnerabilities on weekends will outperform a staff engineer who treats the role as an unwanted chore.

Criteria that matter

Interest over experience. The best champions often have no formal security training. They just ask questions like “what happens if someone sends a negative number here?” during code review. That instinct is hard to teach.

Team influence. Champions need to be heard. A developer whose opinions are regularly dismissed by the team will struggle to change behavior. Pick someone whose team already listens to them.

Willingness. Never force the role on anyone. Mandatory champions produce nothing. Start with a call for volunteers, explain what the program offers (training, visibility, career growth), and let people opt in.

Rotation vs. permanent roles

Some programs rotate the champion role every 6-12 months to spread knowledge. Others keep champions in place permanently to build deep expertise. Both work. Rotation is better for smaller orgs where you want everyone to develop some security awareness. Permanent roles work better in larger orgs where champions accumulate institutional knowledge about their team’s attack surface.

How many champions you need

A ratio of 1 champion per 8-12 developers works for most organizations. Every team that writes production code should have at least one champion. Teams that handle sensitive data (payments, authentication, PII) may benefit from two.

Training curriculum

Champions need structured training, not a one-time onboarding session followed by silence. The most effective programs run quarterly half-day workshops combined with ongoing self-paced learning.

Quarterly workshops

Run a half-day session every quarter. Keep each workshop focused on a single topic rather than covering everything. A good first-year rotation:

• Q1: Threat modeling basics. Teach champions to draw data flow diagrams and identify trust boundaries. Practice with a real system from your codebase.
• Q2: OWASP Top 10 deep dive. Walk through the current list with code examples from your own repositories. Show what each vulnerability looks like in your tech stack.
• Q3: Secure code review. Teach champions what to look for when reviewing pull requests: input validation, authentication checks, SQL construction, file path handling, and deserialization.
• Q4: Incident response and triage. Walk through how your team handles vulnerability reports. Teach champions to assess severity, determine exploitability, and write clear remediation tickets.

Self-paced resources

Between workshops, give champions access to structured learning. OWASP Web Security Testing Guide and OWASP Application Security Verification Standard are free and thorough. Commercial platforms like Secure Code Warrior and Kontra provide interactive challenges mapped to real vulnerability patterns.

Set a target of 2-4 hours of self-study per month. Track completion but do not make it punitive. The goal is growth, not compliance theater.

Certifications

Encourage but do not require certifications. The ISC2 CC (Certified in Cybersecurity) is a free entry-level certification that gives champions a baseline vocabulary. For champions who want to go deeper, the CSSLP or CEH provide structured learning paths. Sponsor exam fees as part of the program.

Day-to-day champion responsibilities

Champions typically spend 10-20% of their time on security activities. In practice:

Review high-risk pull requests. When a PR touches authentication logic, authorization checks, cryptographic operations, or data handling for PII, the champion reviews it with a security lens. This does not mean every PR. It means the ones where mistakes carry real consequences.

Triage vulnerability findings. When a SAST or SCA scanner flags issues in the team’s code, the champion takes the first look. They assess whether the finding is a true positive, determine severity in the team’s context, and either fix it directly or create a ticket with enough detail for another developer to pick up.

Answer security questions. “Is it safe to store this in localStorage?” “Should we use bcrypt or argon2?” “How do I validate this file upload?” These questions used to queue for the security team. Champions handle the common ones immediately.

Attend monthly champion meetings. Champions meet monthly (30-60 minutes) with the security team to share patterns they are seeing, learn about new threats, and raise concerns. This meeting is the primary feedback channel between engineering teams and the security program.

Escalate what they cannot handle. Champions are not expected to perform penetration testing or design cryptographic protocols. When something exceeds their knowledge, they escalate to the security team with context. A good escalation includes what the team is trying to do, what security concern exists, and what options they have considered.

Incentives and recognition that work

The fastest way to kill a champion program is to add security responsibilities to someone’s plate without acknowledging the extra work. Champions need visible recognition and real benefits.

What works

A formal title. “Security Champion” in the company directory and on their Slack profile. This signals organizational support and gives the role legitimacy.

A dedicated Slack or Teams channel. Champions need a space to ask each other questions, share findings, and discuss patterns. This peer network often ends up being what champions value most about the program.

Access to leadership. A quarterly meeting with the CISO or VP of Engineering where champions share what they are seeing on the ground. This gives champions influence and gives leadership unfiltered signal from the engineering floor.

Conference and training budget. Sponsor attendance at security conferences like OWASP Global, BSides, or Black Hat. Budget $1,500-$3,000 per champion annually for conferences and training. This is cheap compared to hiring another security engineer.

Certification sponsorship. Pay for exam fees and study materials. A champion who earns a security certification has more career options, which makes the role attractive to high performers.

Career path recognition. Work with engineering management to ensure champion contributions count in performance reviews. Security work that goes unrecognized in promotion discussions will not attract top talent.

What does not work

Pizza and stickers. Swag is fine as a supplement, but it is insulting as the primary incentive for a role that takes 4-8 hours per week.

Mandatory participation. Forcing developers into the role produces disengaged champions who attend meetings but contribute nothing.

Blame assignment. If champions get called out when their team ships a vulnerability, nobody will volunteer next quarter.

Measuring program effectiveness

You need to show that the champion program produces results. Track these metrics from day one so you have a baseline.

Metrics to track

Vulnerability escape rate by team. Compare teams with active champions against teams without. After 6 months, teams with engaged champions should show a lower rate of vulnerabilities reaching production.

Mean time to remediate (MTTR). Measure how long it takes champion-supported teams to fix vulnerabilities versus the organization average. Champion teams typically fix findings 30-50% faster because someone on the team can evaluate the finding and start remediation without waiting for the security team.

Champion engagement. Track workshop attendance, monthly meeting participation, and security PR reviews. A champion who attends zero meetings in a quarter is not functioning in the role.

Security question volume to central team. If the champion program works, the number of ad-hoc security questions reaching the AppSec team should decrease over time as champions handle the common ones locally.

Training completion. Track hours of self-paced learning and certifications earned. This is a leading indicator — champions who invest in learning produce better outcomes.

Reporting cadence

Share metrics quarterly with engineering leadership. Keep the report to a single page: champion participation rates, vulnerability trends for champion vs. non-champion teams, and any notable catches or escalations.

For a deeper look at AppSec measurement, see the AppSec Metrics & KPIs guide.

Common mistakes and how to avoid them

Launching without executive buy-in. If engineering managers do not support the program, champions will not get the 10-20% time allocation they need. Get VP-level sign-off before selecting your first champion.

Training once and disappearing. A single onboarding session does not produce effective champions. Ongoing quarterly training, monthly meetings, and accessible resources are what sustain the program.

Selecting only senior engineers. Senior engineers are often overcommitted. Mid-level developers with genuine curiosity frequently make better champions because they have more bandwidth and are still building their technical identity.

No clear scope. If champions do not know where their responsibilities start and stop, they either take on too much and burn out, or take on too little and add no value. Write a one-page role description that defines what champions do and do not own.

Ignoring the feedback loop. Champions see problems that the security team misses. If you collect their feedback in monthly meetings but never act on it (fixing noisy scanner rules, improving documentation, adjusting SLAs), champions will stop sharing and eventually disengage.

Scaling too fast. Start with 3-5 champions from willing volunteers. Prove the model works, document what you learn, then expand. Launching with 20 champions across the entire org before you have figured out the training cadence and meeting format leads to a diluted, ineffective program.

For more on building a broader AppSec program, see the DevSecOps hub. If you are evaluating tools for your champion teams to use, the ASPM guide covers how to consolidate scanner findings into a single prioritized view.

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.