Security Champions Program: Building Developer Security Culture That Sticks
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Security organizations face an arithmetic problem that cannot be solved with hiring. At a ratio of one security engineer per 100 or more developers, the security team cannot review every architectural decision, attend every sprint planning meeting, or provide timely feedback on every pull request that touches security-sensitive code. The response in most organizations is to triage ruthlessly, focus on the highest-risk systems, and accept that lower-priority systems receive little security attention. This produces the predictable outcome: vulnerabilities accumulate in the systems that security rarely touches, which are often the same systems that have been running unchanged for years and handle data the organization considers low-risk until it is breached. Security champions solve the scaling problem by embedding security capability in engineering teams rather than concentrating it in a central security org. A well-run program trains developers who are interested in security, gives them real skills rather than compliance awareness, and creates a two-way channel between security and engineering that improves both the security team's context and the engineering team's security posture. This guide covers every stage of building a program that persists: champion selection, the curriculum that builds real skills, the ongoing engagement model that prevents attrition, and the metrics that distinguish genuine culture change from a participation checkbox.
The Scaling Problem and What Security Champions Are Not
The ratio problem is structural and does not improve with security team growth at the rates most organizations can afford. A security team growing at 15% annually while the engineering organization grows at 30% annually is falling behind in absolute terms regardless of the hiring investment. The only sustainable solution is to distribute security capability into the engineering teams themselves, which is what security champions programs attempt to do.
Before defining what a security champion is, it is worth being explicit about what the role is not, because mischaracterizing it leads to program designs that fail. A security champion is not a part-time security engineer. Treating champions as unpaid security engineering capacity that handles security reviews, vulnerability triage, and compliance tasks burns champions out within months and discourages future participation. The champion role is additive to the developer's primary responsibilities, not a responsibility transfer from the security team.
A security champion is also not a compliance checker. Programs that focus champion activities on ensuring developers complete security training modules or sign off on security policies produce exactly the compliance-theater culture that security programs are trying to replace. Champions are most effective when they are respected members of their engineering team who can influence technical decisions and bring security considerations into design conversations, not when they are enforcement agents for security policy.
The accurate description of the role: a security champion is a developer who has demonstrated interest in security, has received focused training to develop practical security skills, and serves as the primary liaison between their engineering team and the security organization. The champion helps their team understand and apply security requirements in context, facilitates threat modeling for features in their domain, provides first-pass triage for security findings in their team's code, and surfaces patterns and constraints from the engineering side back to the security team. The relationship is bidirectional and based on technical collaboration rather than oversight.
Champion Selection and Onboarding
Champion selection determines program quality more than any other factor. A champion who is nominated reluctantly, who does not have the respect of their peers, or who lacks genuine interest in security will be ineffective regardless of the training provided. Three characteristics predict effective champions: genuine curiosity about how systems break (the mindset that asks "what could go wrong" rather than "what should work correctly"), strong communication skills that allow them to explain security concepts to non-security audiences, and credibility with their engineering team peers built through technical competence.
The voluntary versus nominated question requires pragmatic thinking. Pure volunteer programs attract the champions who would have learned security independently anyway, but may miss excellent candidates who would be effective if approached. Pure nomination programs risk placing unwilling participants in the role. The effective approach is a hybrid: the security team identifies candidates through engineering manager conversations and existing interactions (developers who ask good security questions in code review, developers who have independently found security issues), then approaches candidates individually with a clear description of the time commitment and benefits rather than broadcasting a general call for volunteers.
Engineering management buy-in is essential before approaching individual candidates. Champions need protected time for program activities: typically two to four hours per week for the first three months during active curriculum work, and one to two hours per week for ongoing activities thereafter. Without explicit manager support for this time allocation, champions experience conflict between champion activities and sprint commitments that eventually resolves in favor of sprint commitments. Framing the program for engineering managers as professional development investment for their team members (security skills are increasingly valuable for developer career progression) is more persuasive than framing it as security team resourcing.
The onboarding period sets expectations and builds the foundation for subsequent champion activities. A welcome meeting with the security engineering lead that explains the program structure, the champion's role, and the two-way nature of the relationship starts the engagement correctly. Champions should receive access to security tooling (SAST results for their team's repos, dependency scanning dashboards, the security team's Jira board) from day one. Visibility into the security team's actual work context gives champions realistic insight into what the security team deals with and why their help is valuable.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The Training Curriculum: Building Real Security Skills
Most security awareness training programs fail to build real skills because they optimize for compliance metrics (completion rate, pass rate on knowledge checks) rather than skill development. A security champions curriculum needs to produce developers who can independently identify common vulnerability classes in code, facilitate a basic threat model for a new feature, and triage SAST/SCA findings with enough confidence to separate true positives from false positives. This requires a different curriculum design than generic security awareness training.
The 8 to 12 week onboarding curriculum covers four areas in sequenced depth. The first area is the OWASP Top 10 and OWASP API Security Top 10, taught through code-level examples in the languages and frameworks the champion's team uses rather than through generic examples. A Python developer understanding SQL injection through a Django ORM example retains the knowledge better than the same developer learning through a generic PHP example. The goal is not just awareness that SQL injection exists, but recognition of the specific code patterns in their technology stack that introduce it.
The second area is threat modeling fundamentals. Champions do not need to master formal threat modeling methodologies like STRIDE or PASTA; they need enough threat modeling skill to facilitate a structured "what could go wrong" conversation for a new feature design. The practical curriculum covers: drawing a data flow diagram for a feature, identifying trust boundaries and external inputs, generating a list of potential threats using a simple threat enumeration checklist, and assessing mitigations. Running a threat modeling exercise on a real upcoming feature in their team as a curriculum exercise is more effective than theoretical training.
The third area is vulnerability triage. Champions who can look at a SAST finding and determine whether it is a true positive, false positive, or accepted risk save the security team significant triage time and get their team actionable findings faster. This area covers reading SAST output from the tools the organization uses (Semgrep, CodeQL, Checkmarx), understanding the common false positive patterns for each finding type, and the security criteria for accepting risk on a finding that cannot be immediately remediated.
The fourth area is security requirement advocacy, which covers how to translate security requirements into sprint stories, how to advocate for security investment in sprint planning when competing against feature development priorities, and how to escalate security concerns to the security team through appropriate channels. This area is often underweighted in champion curricula but is critical for champions to have lasting impact on their teams' security posture.
Ongoing Engagement and Champion Activities
The attrition problem in security champion programs is well-documented. Champions who complete the onboarding curriculum and then receive no ongoing support, no new challenges, and no recognition frequently disengage within six months. The program structure must maintain champion engagement through ongoing learning opportunities, real activities in their teams, and visibility across the champion community.
Monthly security champion meetings are the most important ongoing engagement mechanism. The format that sustains participation is a working session rather than a status update: present a recent real vulnerability (anonymized if from the organization, or a notable public disclosure), walk through how it was introduced and exploited, discuss how it could have been detected earlier, and connect it to the tools and practices the champions use in their teams. Champions who attend these meetings leave with actionable knowledge they can apply, which sustains engagement. Meetings that consist primarily of security team status updates and policy reminders do not.
CTF (capture the flag) participation gives champions a low-stakes competitive environment to develop offensive security thinking. Security teams that provide access to CTF platforms (HackTheBox, TryHackMe, PicoCTF) and organize champion CTF teams see measurably better skill development than those that rely only on curriculum training. The offensive mindset developed through CTF is directly applicable to the defensive work champions do in their teams: a developer who has exploited an IDOR vulnerability in a CTF environment will naturally check for IDOR patterns in their own code.
Bug bounty program engagement, where the organization has one, is another valuable ongoing development mechanism. Reviewing public bug bounty reports (the public disclosed reports on HackerOne and Bugcrowd) gives champions visibility into how real attackers find real vulnerabilities in production applications and provides concrete examples of the vulnerability patterns they are responsible for preventing in their own codebases. Some organizations give champions access to review findings in their own bug bounty program, which directly connects champion learning to the organization's actual attack surface.
Champion-driven activities in their engineering teams are what translate training investment into security posture improvement. The specific activities should be agreed with engineering management and documented in the champion's development plan: participating in at least one security review per sprint, facilitating threat modeling for features above a defined complexity threshold, reviewing and triaging SAST and SCA findings for the team's repos on a weekly basis, and serving as the first point of contact for security questions before they reach the central security team.
Recognition, Retention, and the Feedback Loop
Champion attrition is the primary risk to program sustainability. The champions who leave the program are disproportionately the most effective ones: competent developers with strong security skills are attractive candidates for security engineering roles, and organizations that do not actively retain them lose their investment. Recognition and career development credit are the primary retention levers.
Public recognition in the forms that resonate with developers includes: crediting champions by name in security blog posts and incident post-mortems where their work was relevant, nominating champions for internal engineering awards, and creating a visible champion tier structure (associate champion, champion, senior champion, champion lead) that reflects growing skill and contribution. Title recognition without substantive content (a badge that has no associated privileges or visibility) does not meaningfully drive retention.
Conference speaking is a high-visibility recognition mechanism for senior champions. A champion who has been running the program for two years and can present a talk on "How We Reduced Authentication Vulnerabilities by 70% Through Security Champions" at a regional security conference receives career development value that is difficult to provide through other means. The security team benefits from the external visibility, the champion benefits from the speaking credential, and the presentation process reinforces the champion's knowledge and communication skills.
The feedback loop between champions and the security team is the mechanism by which security program quality improves over time. Champions embedded in engineering teams observe why security requirements are difficult to implement, what tooling generates excessive false positives that developers learn to ignore, what security guidance is unclear or contradictory, and what architectural decisions are creating recurring vulnerability patterns. This is information the central security team cannot easily obtain through scanning and testing alone. Structured feedback collection through quarterly champion surveys and monthly meeting discussion time dedicated to "what is making security harder in your team" converts champion observations into program improvements.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Metrics and Scaling the Program
Measuring the program requires distinguishing between activity metrics (how many champions exist, how many meetings they attend) and outcome metrics (whether security posture has measurably improved in champion-covered teams). Activity metrics are easy to collect and show a positive trend almost by definition as the program grows. Outcome metrics are harder to collect but are the only evidence that the program is achieving its purpose.
The core outcome metrics are: mean time to remediate security findings by team (comparing champion vs. non-champion teams), security finding discovery rate by team (do champion teams find and fix vulnerabilities before they are reported by scanners or external testers), and the rate at which security requirements are incorporated at design time versus added post-development as findings. This last metric requires tracking when in the development lifecycle security requirements are addressed, which necessitates process instrumentation in the development workflow.
Champion satisfaction surveys run quarterly provide early warning of engagement issues before they produce attrition. Four questions cover the most predictive dimensions: whether the champion feels their security recommendations are taken seriously by their team, whether they feel supported by the security team with sufficient access and responsiveness, whether the time commitment is sustainable given their other responsibilities, and whether they see a clear career development path connected to their champion role. Satisfaction scores below 3 on a 5-point scale on any dimension predict attrition with reasonable reliability.
Scaling the program from a pilot covering two to three teams to an organization-wide program covering 50 or more champions requires a champion lead role that manages program operations. The security engineer who launches the program can personally manage 10 to 15 champions effectively; beyond that, the program needs a champion lead (typically a senior champion who has transitioned to a security-adjacent role) who handles champion onboarding, curriculum delivery, and community management while the security engineering team focuses on technical support and strategic direction. The champion lead role creates a career path for highly engaged champions that retains institutional knowledge in the program rather than losing it when top champions move into security engineering roles.
The bottom line
Security champions programs succeed when they are built on genuine skill development rather than compliance awareness, and when they create a two-way relationship between security and engineering rather than a one-way policy enforcement channel. The structural requirements are non-negotiable: voluntary participation, explicit management support for time allocation, a curriculum that builds real skills in the champion's technology context, and outcome metrics that measure security posture improvement rather than participation. Start with a pilot of three to five carefully selected champions in teams where the engineering managers are enthusiastic supporters. Run a full 10-week curriculum before expanding. Measure MTTR for security findings in pilot teams versus control teams after six months. If the pilot shows measurable improvement, the data makes the case for expansion. If it does not, the data identifies what needs to change in the curriculum or engagement model before scaling.
Frequently asked questions
How much time should a security champion realistically commit to the program each week?
During the initial 8 to 12 week curriculum period, champions should expect to spend 3 to 4 hours per week on curriculum activities: reading and exercises, attending the weekly champion cohort call, and applying concepts in their team's current work. After the curriculum period, the ongoing commitment averages 1 to 2 hours per week for program activities: attending monthly champion meetings, triaging SAST findings for their team's repos, participating in security reviews for significant features, and occasional champion-specific tasks like threat modeling facilitation. The 1 to 2 hour ongoing commitment is what should be explicitly discussed with engineering managers during the buy-in conversation, because it is the sustainable long-term figure that managers are committing to when they approve their developer's participation.
What happens when a security champion's security recommendation is overridden by their engineering manager or tech lead?
Champions are advocates, not approvers. They do not have veto power over engineering decisions, and the program design should not imply that they do. When a champion's security recommendation is overridden, the appropriate path is: document the decision and the security concern in the ticket or design doc so the context is preserved, escalate to the security team if the champion believes the risk is significant enough to warrant central security team review, and accept the team's decision if the security team agrees the risk is acceptable or not worth the development investment. Champions who escalate every overridden recommendation to the security team become friction rather than enablers. Champions who never escalate legitimate high-risk decisions are not fulfilling their role. Calibrating this judgment is part of the ongoing mentoring the security team should provide.
How do you handle a situation where a strong champion leaves the team or the company?
Champion departure is the primary structural risk to program continuity and should be planned for explicitly. Each team should have a champion succession plan that identifies one or two developers who could be developed into the champion role if the current champion leaves. The departing champion should be asked to participate in a knowledge transfer session where they brief the security team on the security context of their team's systems, active risks they were tracking, and relationships with team members who are interested in security. If the departure is to an external role, a transition period of two to four weeks where the departing and successor champion overlap is valuable. Organizations that treat champion departure as a crisis rather than a planned transition lose significant program continuity unnecessarily.
Should the security champion program have a formal policy or charter?
A lightweight charter is useful for setting expectations with engineering management and establishing program governance, but the document should be brief (one to two pages) and focused on the practical elements that matter: the time commitment, the activities expected of champions, the support the security team provides to champions, and the escalation path for high-risk issues. An overly formal charter with detailed role descriptions and approval workflows creates the impression of a bureaucratic compliance program rather than a collaborative community, which affects champion recruitment quality. The charter serves the practical purpose of giving engineering managers a concrete document to discuss with their teams when deciding whether to participate.
How do you measure whether the security champions program is actually improving security outcomes?
The most reliable outcome metric is the comparative finding rate and remediation speed between champion-covered and non-champion-covered teams. Pull vulnerability data (from SAST, DAST, bug bounty, or penetration testing) and segment it by team. Compare: the number of vulnerabilities found per thousand lines of code, the age of vulnerabilities at time of discovery (were they caught early or late?), and the time from discovery to remediation. Champion-covered teams that show lower vulnerability density, earlier discovery, and faster remediation are demonstrating real security posture improvement. This analysis requires consistent data collection practices across teams and should be run quarterly after the program has been in operation for at least six months to accumulate sufficient data for meaningful comparison.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.