Here is a math problem every security leader faces: you have 3 AppSec engineers and 200 developers. Those 3 engineers cannot review every design, every PR, and every deployment. They will burn out trying. The security champions model solves this by embedding security-minded developers throughout engineering teams who act as force multipliers for your security program.
I have helped build champions programs at two organizations, and the difference between one that thrives and one that fizzles out within six months comes down to execution details that most guides skip.
What a Security Champion Actually Does
A security champion is a developer who voluntarily takes on security responsibilities within their team. They are not security professionals. They are developers who care about security and are given the knowledge and support to make a difference.
Their typical responsibilities include:
- Being the first point of contact for security questions within their team.
- Reviewing code changes for common security issues.
- Ensuring security requirements are considered during design discussions.
- Triaging and tracking vulnerability remediation within their team's projects.
- Attending monthly security sync meetings and cascading relevant information.
- Testing new security tools and providing feedback.
What they should not do: replace the security team. Champions handle the routine security work and escalate complex issues. The AppSec team handles threat modeling, penetration testing, architecture reviews, and incident response.
Step 1: Get Leadership Buy-In
This will not work without explicit support from engineering leadership. Champions need time allocated for security activities, typically 10-15% of their work week. Without this, security work competes with feature delivery and always loses.
Build the business case around:
- Scalability. Your security team cannot grow linearly with engineering. Champions are a cost-effective force multiplier.
- Speed. Security issues caught during development cost 10x less to fix than those found in production.
- Retention. Developers in champion programs report higher job satisfaction due to skill growth and cross-team visibility.
- Risk reduction. Teams with champions have measurably fewer security issues reaching production.
Get a written commitment that champions will have dedicated time for security activities and that their performance reviews will account for their champion role.
Step 2: Define the Program Structure
One champion per team. Larger teams (10+ developers) might benefit from two. The champion should be embedded in the team, not pulled out into a separate org.
Voluntary participation. Forcing someone into the role guarantees resentment and mediocre effort. Look for developers who already show interest in security topics, ask good security questions in code reviews, or voluntarily fix vulnerability alerts.
Fixed term with renewal. Twelve months is a good initial term. This prevents burnout and creates natural transition points. Champions who enjoy the role can renew. Those who do not can step down without stigma.
Clear escalation paths. Champions need to know exactly when to handle something themselves and when to bring in the AppSec team. Define these boundaries explicitly.
Step 3: Recruit Your First Cohort
Start small. Five to eight champions is ideal for the first cohort. You want enough to build community but few enough to give each person meaningful support.
Recruitment channels:
- Ask team leads for nominations of developers who show security awareness.
- Post an internal application. Describe the role, time commitment, and benefits clearly.
- Look at your bug bounty or vulnerability fix history. Developers who voluntarily fix security issues are natural champions.
Selection criteria:
- Genuine interest in security (not just doing it for a promotion checkbox).
- Respected by their peers (a champion's influence depends on credibility).
- Enough experience to understand their team's codebase and architecture.
- Willingness to dedicate consistent time, not just initial enthusiasm.
Step 4: Training
This is where most programs underinvest. You cannot hand someone the title "security champion" and expect them to be effective without training.
Initial Training (Week 1-4)
Cover the fundamentals through a mix of instructor-led sessions and self-paced materials:
- OWASP Top 10 with hands-on examples relevant to your stack.
- Your organization's security policies and standards.
- How to use your security tools (SAST, SCA, secret scanning).
- Secure code review techniques.
- How to file and triage security issues in your tracking system.
- Threat modeling basics (STRIDE or similar lightweight methodology).
Ongoing Training (Monthly)
- Monthly security sync where the AppSec team shares new threats, tool updates, and lessons learned.
- CTF events or challenge platforms like OWASP WebGoat for skill building.
- Conference talk watch parties (pick a relevant talk, watch together, discuss).
- Incident post-mortem reviews (sanitized) so champions learn from real events.
Advanced Training (Quarterly)
For champions who have been in the role six months or more:
- Threat modeling facilitation.
- Security architecture review.
- Vulnerability research basics.
- Presenting security topics to their teams.
Step 5: Tooling and Access
Champions need access to the same security tools the AppSec team uses. At minimum:
- Read access to vulnerability dashboards for their team's projects.
- Ability to run SAST and SCA scans on demand.
- Access to the security knowledge base or wiki.
- A dedicated Slack or Teams channel for champion discussions.
- Direct communication line to the AppSec team (not through a ticketing system for quick questions).
Step 6: Recognition and Incentives
People leave champion programs for two reasons: they run out of time, or they feel their effort is invisible. Address both.
Formal recognition:
- Include champion contributions in performance reviews.
- Champion role listed on internal profiles and org charts.
- Annual awards for outstanding champion contributions.
- Conference attendance budget for champions.
Informal recognition:
- Public shout-outs in all-hands meetings for champions who catch significant issues.
- Security team blog posts highlighting champion wins.
- Champion-specific swag (subtle, but surprisingly effective).
Career development:
- Champions often transition into security roles. Support this path explicitly.
- Provide mentorship from senior security engineers.
- Certifications sponsorship (Security+, CEH, or OSCP for those who want to go deep).
Step 7: Measure and Iterate
Track metrics that show program impact:
- Coverage: Percentage of engineering teams with an active champion.
- Engagement: Champion attendance at monthly syncs. Champions who stop showing up are disengaging.
- Security issue catch rate: Vulnerabilities identified by champions before reaching production.
- Time to remediate: Compare remediation speed for teams with champions versus teams without.
- Knowledge sharing: Number of security-related discussions, wiki articles, or presentations by champions.
Review metrics quarterly and adjust the program based on what you learn. If champions report they do not have enough time, go back to leadership for more allocation. If training is not sticking, change the format.
Common Pitfalls
Starting too big. Launching with 30 champions before you have the support infrastructure guarantees a bad experience. Start with 5-8 and scale after proving the model.
Making it mandatory. Assigned champions are passive champions. Voluntary participation filters for people who will actually do the work.
No executive sponsor. When a reorg happens or budgets get cut, someone at the VP level needs to protect the program.
Treating champions as the security team's task runners. If champions feel like they are just doing the security team's grunt work, they will leave. They should feel empowered, not exploited.
How Safeguard.sh Helps
Safeguard.sh gives security champions the visibility they need without requiring deep security expertise. Champions can see their team's vulnerability status, track remediation progress, and understand risk through intuitive dashboards. The platform provides the shared context that makes champions effective, showing what needs fixing, why it matters, and how to prioritize. For security teams building a champions program, Safeguard.sh is the tool you put in champions' hands on day one.