Every security team hits the same scaling wall. You have three security engineers and forty development teams. You cannot be in every design review, every code review, and every sprint planning session. Features ship faster than you can review them. The backlog of security work grows. Engineers treat security as someone else's problem.
A security champions program solves this by embedding security-minded engineers inside every team. Not dedicated security staff. Not reassigned headcount. Existing engineers who volunteer to be their team's security point of contact, receive additional training, and carry the security flag in their daily work.
Done well, a champions program is the highest-leverage investment a security team can make. Done poorly, it is a list of names on a Confluence page that nobody remembers signing up for. Here is how to build one that works.
What a Security Champions Program Actually Is
A security champions program is a formal structure where volunteer engineers from each development team receive additional security training and take on specific security responsibilities within their team. Champions are not security professionals. They are engineers who happen to care about security and have been given the tools and authority to act on it.
The champion serves as a bridge between the central security team and their engineering team. They review code for security issues, raise security concerns during design discussions, triage vulnerability findings for their team's applications, and escalate complex issues to the security team. They reduce the bottleneck that a small security team creates when it tries to be involved in everything.
What champions do
- Security-focused code reviews for their team's pull requests, especially for authentication, authorization, and data handling changes
- Threat modeling participation during design phases of new features
- Vulnerability triage for findings from scanners and pentests that affect their team's applications
- Knowledge sharing by bringing lessons from champion training back to their team
- Security tool advocacy by helping their team adopt and use SAST, DAST, and dependency scanning tools in CI/CD
- Incident support by serving as the first responder for security issues in their team's domain
What champions are not
Champions are not a replacement for a professional security team. They do not perform penetration tests. They do not architect security infrastructure. They do not own the security program. They are force multipliers who extend the security team's reach across the organization. The security team still owns strategy, tooling, policy, and deep technical testing. Champions own the day-to-day security hygiene within their teams.
Why It Scales Security Culture
The math behind a champions program is compelling. If you have a 3-person security team and 40 engineering teams, each team gets roughly 2% of security's attention. Add 40 champions spending 15% of their time on security activities, and you have effectively added the equivalent of 6 full-time security engineers to the organization, at zero additional headcount cost.
But the real value is cultural, not mathematical. When security feedback comes from a teammate rather than an external security team, it lands differently. Engineers are more receptive to security guidance from someone who understands their codebase, their deadlines, and their constraints. The feedback loop is shorter. The context is richer. The friction is lower.
Champions also create a security culture that persists even when the security team is not in the room. When the champion asks "have we thought about the security implications of this?" during a design review, it normalizes security thinking as part of engineering, not as an external gate that slows things down.
The cultural shift: Without a champions program, security is something that happens TO engineering teams (audits, pentest findings, compliance requirements). With a champions program, security is something that happens WITHIN engineering teams. That distinction changes everything.
How to Recruit Champions (Without Voluntelling)
The single biggest determinant of program success is how you recruit your champions. Mandating participation kills the program before it starts. The best champions are intrinsically motivated. They are the engineers who already ask security questions in code reviews, who read about vulnerabilities in their spare time, who get excited when they find a bug in their own code.
Recruitment strategies that work
- Open nomination with self-selection. Announce the program, explain the benefits (training, career development, recognition), and let people volunteer. You will be surprised who raises their hand.
- Manager nomination with opt-in. Ask engineering managers to suggest team members who have shown interest in security, then let those individuals decide whether to participate.
- Start with a pilot. Launch with 3-5 teams, prove the value, then use the pilot champions as advocates when expanding to the full organization.
- Make it prestigious. Frame the champion role as a career development opportunity, not additional unpaid work. Tie it to promotion criteria and professional growth.
Who makes a good champion
The best champions are not necessarily the most senior engineers. Look for engineers who are curious about how things break, who have strong communication skills, and who are respected by their peers. Technical depth matters less than the ability to influence team behavior and translate security concepts into practical engineering decisions.
Avoid recruiting only from the backend team. Frontend engineers, mobile developers, infrastructure engineers, and QA engineers all bring unique security perspectives. A diverse champion cohort catches a wider range of issues.
The Training Curriculum That Keeps Champions Engaged
A one-time training session does not create a security champion. It creates someone who attended a training once and then forgot about it. Champions need ongoing, structured learning that builds on itself and stays relevant to their daily work.
Month 1-3: Foundation
- OWASP Top 10 deep dive with hands-on labs (PortSwigger Web Security Academy, Hack The Box)
- Secure coding practices specific to the company's tech stack
- Threat modeling basics using STRIDE or PASTA methodology
- How to perform a security-focused code review
- Introduction to the company's security tools and how to read their output
Month 4-6: Applied skills
- Reviewing real penetration test findings from the company's own assessments
- Authentication and authorization pattern review for the company's architecture
- Dependency and supply chain security assessment
- Security testing in CI/CD: integrating SAST, DAST, and SCA tools
- Incident response basics and the champion's role during incidents
Ongoing: Monthly cadence
- Monthly champion meetup (1 hour) to discuss recent findings, share learnings, and review new threats
- Quarterly CTF events to maintain and develop offensive security skills
- Annual external training budget for conferences or certifications (SANS, Offensive Security)
- Rotating "vulnerability of the month" where one champion presents a recent CVE or finding to the group
The key is that training is continuous, practical, and tied to the company's own codebase and findings. Champions who train on abstract examples lose interest. Champions who train on their own application's real code review findings stay engaged because the learning is immediately applicable.
Incentive Structures That Actually Motivate
Asking engineers to take on additional responsibilities without recognition or reward is a fast path to program collapse. The incentive structure does not need to be expensive, but it needs to exist and be visible.
Career incentives
The most powerful incentive is career advancement. Work with engineering leadership to ensure that security champion participation is explicitly recognized in performance reviews and promotion decisions. Add "security champion" to the engineering career ladder as a recognized specialization. Engineers who can demonstrate security expertise alongside their core engineering skills are more valuable, and the organization should reflect that.
Learning incentives
Provide champions with a dedicated training budget. Access to paid training platforms, conference attendance, and certification sponsorship are tangible benefits that attract motivated engineers. If the company would not otherwise pay for a SANS course, but a champion can earn one through active participation, that is a meaningful draw.
Recognition incentives
- Monthly security MVP award for the champion who made the most impactful contribution
- Quarterly all-hands recognition where champion contributions are highlighted to the entire engineering org
- Annual "Security Champion of the Year" with a meaningful reward (extra PTO, equipment budget, conference trip)
- Internal blog or newsletter featuring champion stories and accomplishments
Time incentives
This is non-negotiable. Champions must have formally allocated time for security activities. If the champion's manager expects 100% delivery velocity while the champion spends 15% of their time on security, the champion will either burn out or quietly drop the security work. Work with engineering leadership to adjust sprint capacity for champions and make it explicit in their team's planning.
Implementation: A Practical Rollout Plan
Rolling out a champions program across an entire engineering organization at once is a recipe for a program that exists on paper but not in practice. A phased approach builds momentum and allows you to iterate on what works.
Phase 1: Foundation (Weeks 1-4)
- Get executive sponsorship from the VP of Engineering or CTO. Without top-down support, the program will be deprioritized.
- Define the champion role: responsibilities, time commitment, incentives, and success criteria.
- Select 3-5 pilot teams, prioritizing teams that work on security-critical applications.
- Recruit pilot champions through open calls and manager recommendations.
- Prepare the initial training curriculum.
Phase 2: Pilot (Months 2-4)
- Run the foundation training for pilot champions.
- Establish the monthly champion meetup cadence.
- Assign pilot champions their first real tasks: security code review for an upcoming release, or triage of recent pentest findings for their team.
- Collect feedback from champions and their managers weekly.
- Iterate on the program structure based on what is and is not working.
Phase 3: Expansion (Months 5-8)
- Use pilot champions to recruit the next wave. Peer advocacy is more effective than top-down mandates.
- Expand to all engineering teams, aiming for one champion per team.
- Launch the first quarterly CTF event.
- Formalize the training curriculum based on pilot learnings.
- Begin tracking program metrics (covered in the next section).
Phase 4: Maturity (Months 9-12)
- Champions begin mentoring newer champions.
- Integrate champion responsibilities into the engineering career ladder.
- Champions participate in vendor evaluations and security architecture decisions.
- Publish the first annual program report to leadership showing measurable impact.
Measuring Success: Metrics That Prove the Program Works
A champions program without metrics is a program that will lose its budget in the next cost-cutting cycle. You need to demonstrate measurable impact to justify the time investment from engineering teams.
| Metric | What It Measures | Target |
|---|---|---|
| Vulnerability escape rate | Findings that reach production vs. caught in development | 30% reduction in Year 1 |
| Time to remediate | How fast champion teams fix findings vs. non-champion teams | Champion teams 40% faster |
| Security review coverage | Percentage of PRs that receive security-focused review | 80% for high-risk changes |
| Champion retention | Percentage of champions still active after 12 months | Above 70% |
| Threat models completed | Number of new features that received threat modeling | All major features |
| Security questions in design | Frequency of security raised in design reviews (survey) | Upward trend quarterly |
| Training engagement | Champion attendance at monthly meetups and CTFs | Above 80% attendance |
The most compelling metric is the vulnerability escape rate comparison between teams with active champions and teams without. If champion teams consistently catch more issues before production, you have undeniable proof that the program works. This is the number that keeps the CTO's support and the engineering managers' buy-in.
Common Pitfalls and How to Avoid Them
We have seen champions programs fail in predictable ways across dozens of organizations. Here are the patterns to watch for.
The "voluntold" champion
When managers appoint champions without their consent, you get disengaged participants who view the role as a burden. Always ensure champions have opted in. If a team cannot produce a willing volunteer, that team is not ready for a champion, and that is okay. Better to have no champion than a resentful one.
No time allocation
If champions are expected to do security work on top of their full engineering workload, the security work will be the first thing dropped when deadlines tighten. Formal time allocation, communicated to and agreed upon by engineering managers, is non-negotiable.
Training stops after onboarding
A one-time training followed by months of silence kills engagement. The monthly cadence of meetups, new content, and hands-on challenges is what keeps champions active and growing. Treat it like a community, not a certification.
No connection to real work
Champions who only receive theoretical training without applying it to their team's actual codebase will disengage. Every training module should connect to a practical task the champion can execute the following week. After reviewing OWASP Top 10 findings, assign champions to check their own team's code for the same patterns.
Security team hoards the interesting work
If the security team only gives champions grunt work (triage these 200 scanner findings) while keeping the interesting work (pentest review, architecture design, tool evaluation) for themselves, champions will feel like unpaid interns rather than valued collaborators. Give champions meaningful, impactful work that develops their skills.
Tying It All Together: Champions as Part of Your Security Program
A champions program does not exist in isolation. It is one layer of a comprehensive security program that includes professional security testing, automated tooling, compliance frameworks, and executive oversight.
Champions catch the everyday issues: insecure defaults in new code, missing input validation, overly permissive IAM roles. Professional penetration testing catches the complex issues that require specialized expertise: chained attack paths, business logic flaws, and authentication bypass techniques that only a trained offensive security professional would find. The two approaches are complementary, not competitive.
At Lorikeet Security, we frequently work with organizations that have champions programs. The best engagements happen when champions participate in the scoping process, join the kickoff call, and help triage findings during the test. Champions who understand the pentest process become better security advocates for their teams, and the pentest produces better results because the testers have access to insider context about how the application works.
If you are thinking about starting a champions program, it is also worth reading our guides on making your first security hire and building security culture at startups. A champions program works best when it is part of a deliberate strategy, not a reactive response to having too few security staff.
Build security into your engineering culture
Lorikeet Security provides penetration testing, code reviews, and security training that give your champions program real-world context. Let us help you build a security practice that scales with your engineering team.
