Building a Security Champions Program: Scaling Security Expertise Into Engineering Teams

Misunderstanding the champion role is the most common cause of program failure. Setting incorrect expectations upfront damages the program's reputation with engineering management and leads to champion burnout.

What security champions are:

• Security-aware engineers who advocate for security within their team
• The first point of contact for security questions within their team (reducing security team interruptions)
• Participants in threat modeling sessions for their team's features
• Reviewers of security-relevant pull requests within their team's codebase
• Attendees of security team syncs who carry information back to their team
• Practitioners who complete security training and share learnings with their team

What security champions are not:

• A replacement for security team code reviews on high-risk changes
• Solely responsible for security outcomes in their team
• Full-time security staff — champion activities are typically 10-20% of their time
• Security gatekeepers whose approval is required before shipping (this creates bottlenecks and resentment)
• People who were assigned to the role rather than volunteering

The critical distinction: Champions amplify the security team's reach; they do not replace security team capacity. A champion program that positions champions as security gatekeepers creates adversarial relationships between engineering and security. A program that positions champions as security-informed advocates creates allies.

The wrong selection process produces champions who are unengaged, resentful, or unable to influence their team. The right selection produces genuine advocates.

Characteristics of effective security champions:

• Intrinsic interest in security: They read security news, experiment with security tools, or have independently researched security topics. This is the most reliable predictor of sustained engagement.
• Respected by their team: A champion with low credibility within their team cannot influence behavior. Ask engineering managers who the technical influencers are.
• Good communication skills: Champions need to translate security concepts for non-security audiences. Technical depth matters less than the ability to make security approachable.
• Sufficient seniority to influence architecture decisions: Junior champions get overruled when raising security concerns. Mid-to-senior engineers or tech leads are the target profile.

Recruitment approaches that work:

• Self-nomination call: Send a program announcement to engineering teams and ask for volunteers. Include a clear description of time commitment and what champions receive (training, access, recognition). Self-selection produces higher engagement than manager nomination.
• Manager nomination with candidate consent: Managers nominate candidates, but candidates must confirm willingness to participate. Mandatory participation is program-killing.
• Existing community identification: Look at who asks security questions in engineering Slack channels, who has taken security training on their own, or who has raised security issues in past code reviews.

Target coverage: One champion per engineering team or product area is the minimum. Two per team is better — champions who leave the company or change teams do not leave coverage gaps. Do not recruit from teams that will not benefit (teams building internal tooling with no external data exposure have lower priority than teams building customer-facing systems).

A champion program that provides a one-day onboarding and calls it training produces champions who feel inadequate answering security questions and stop engaging. A curriculum that builds progressive competence creates confident advocates.

Curriculum structure by phase:

Phase 1 — Foundations (Months 1-2, ~8 hours):

• OWASP Top 10 for Web and API — not a lecture, but hands-on exploitation and remediation in a lab environment (DVWA, WebGoat, Juice Shop)
• Secure coding practices specific to the languages and frameworks used by that team (Python, JavaScript, Java, Go — not generic)
• Introduction to threat modeling — apply STRIDE to a system the champion's team owns
• Security toolchain overview — what SAST, DAST, SCA, and secrets scanning tools are available, how to read their output

Phase 2 — Depth by role (Months 3-4, ~6 hours): Customize by champion's domain:

• Web/API developers: Authentication and authorization patterns, JWT security, OAuth/OIDC implementation, input validation, CORS configuration
• Infrastructure/DevOps: IAC security (Terraform misconfiguration patterns, checkov/tfsec), container hardening, CI/CD pipeline security, secrets management
• Mobile developers: Platform-specific security (iOS/Android), certificate pinning, biometric authentication, storage security

Phase 3 — Applied practice (Ongoing):

• Monthly capture-the-flag (CTF) challenges or security labs
• Access to bug bounty programs or internal red team exercises as observers
• Rotating threat modeling facilitation (champions take turns leading, with security team support)
• Conference talks or papers shared monthly with champion community

Budget and tooling: External security training (SANS, Offensive Security, PentesterLab) budgeted per champion. Access to security testing environments and tools (Burp Suite Pro license, cloud security lab environments). Participation approval for security conferences (OWASP AppSec, BSides events) for engaged champions.

Champions in isolation drift from the program. A community structure keeps champions engaged and informed.

Regular touchpoints:

• Monthly champion sync (60 minutes): Security team presents threat intelligence relevant to the organization's tech stack, new tooling, policy changes, and lessons from recent incidents or code reviews. Champions share security questions or issues from their teams. Recording is mandatory — asynchronous viewing for champions who cannot attend live.
• Quarterly champion workshop (half day): Deep-dive technical training, collaborative threat modeling, or tabletop exercise. Builds community and provides substantial skill development.
• Slack/Teams channel: Dedicated async channel where champions share findings, ask questions, and discuss security topics. Security team actively participates. This is often where the program's most valuable interactions happen.

Champion onboarding for new members: New champions should complete Phase 1 training before their first monthly sync. Assign them a buddy champion from another team for the first 60 days. Pair them with a security team member for their first threat modeling session.

Escalation paths: Document clearly: when should a champion escalate to the security team vs. handle independently? Champions should escalate: any suspected active security incident, any finding in code review they are uncertain how to classify, any architectural decision with significant security implications they cannot resolve with available resources. Champions should handle independently: standard security questions from their team, routine SAST/SCA finding triage, basic threat modeling for low-complexity features.

Champions who perceive the program as value-extracting (the security team gets help, the champion gets nothing) disengage within 6 months. Effective incentive structures make the champion role visibly beneficial to the champion's career.

Career recognition:

• Champion role listed in performance review system as a formal responsibility, not a side activity
• Security team writes a performance input for each champion at review cycles — a direct career benefit
• Champions highlighted in engineering all-hands for security improvements they drove
• Job title recognition: 'Senior Engineer / Security Champion' is visible to recruiters and future employers

Professional development:

• Budget for external security certifications (GWEB, GWAPT, CSSLP) for champions who demonstrate sustained engagement
• Priority access to security conferences the security team attends
• Involvement in security team hiring processes as a technical interviewer (broadens the champion's visibility and influence)
• First access to new security tools or research before general rollout

Practical benefits:

• Pre-scheduled 'champion office hours' with the security team lead — no need to cold-message for help
• Access to security team communication channels and threat intelligence feeds
• Invitation to post-incident reviews as a learning opportunity (without operational responsibility)

Recognition cadence:

• Monthly: Acknowledge champions who resolved security findings or led threat models in the champion channel
• Quarterly: Champion of the quarter recognition with a public callout in engineering communications
• Annually: Program retrospective shared with engineering leadership that attributes specific security improvements to the champion program

The security champion program must demonstrate value to both engineering leadership (who provides champion time) and security leadership (who funds the program). Metrics must be meaningful to both audiences.

Program health metrics:

• Champion coverage rate: What percentage of engineering teams have an active champion?
• Champion retention rate: What percentage of champions are still active at 6 months? 12 months?
• Training completion rate: What percentage of champions have completed Phase 1 and Phase 2 curriculum?
• Monthly sync attendance rate: What percentage of champions attend or view recordings of monthly syncs?

Security outcome metrics:

• Vulnerability-in-code findings before vs. after champion deployment in a team (requires a pre-program baseline)
• Mean time to remediate security findings in teams with champions vs. teams without
• Percentage of security issues raised by champions vs. found in production or by external researchers
• Threat models completed per quarter by teams with champions vs. teams without

Business impact metrics for leadership:

• Reduction in security team time spent on routine developer questions (free capacity for higher-value work)
• Reduction in critical security findings in code review for champion-covered teams
• Cost of a security incident prevented (requires attributing specific prevented issues to champion program activity)

What not to measure: Avoid measuring champion activity volume (number of code reviews, number of questions answered) — these incentivize busy work over impact. Focus on outcomes in the teams champions serve, not activity counts.

68% of security champion programs experience significant attrition within 12 months. The causes are predictable.

Failure mode 1: Mandatory enrollment. Champions who were assigned to the role rather than volunteering disengage quickly. They lack intrinsic motivation and often feel the role was imposed rather than chosen. Fix: make the program invitation-based with genuine voluntary participation.

Failure mode 2: Time commitment not respected by engineering management. Engineering managers who do not value the champion role fill champions' sprint capacity with feature work, leaving no time for champion activities. Champions feel guilty about 'not doing their real job.' Fix: Get explicit time commitment (e.g., 10-20% of time) documented and approved by engineering leadership before program launch, not as an assumption.

Failure mode 3: Champions feel incompetent answering security questions. With insufficient training, champions avoid the role because they fear giving wrong answers. Fix: invest in the training curriculum during the first 60 days before champions are expected to answer questions from their team.

Failure mode 4: No visible career benefit. Champions who cannot point to any career benefit from the role (no recognition, no training, no performance review credit) deprioritize it when workload increases. Fix: build the career incentive structure before launch, not as an afterthought.

Failure mode 5: Security team treats champions as free reviewers rather than partners. If the security team's primary interaction with champions is routing code review requests to them, champions feel exploited. Fix: the security team's primary role in the program is to make champions more capable, not to use their time for security team work.