Take a typical case: 200 developers spread across 25 teams, only 2 AppSec experts, and a vulnerability backlog that grows month after month. Every security question waits until one of the two experts is free. A network of Security Champions, one volunteer per team trained in application security basics, tackles exactly this bottleneck.
This guide is for any DevSecOps or AppSec (application security) team short of experts compared with the number of developers. It walks through a complete method, from the first sponsor to success indicators, with data from the BSIMM16 report (2026) to calibrate your goals, whether you start from scratch or structure an informal programme.
What you will learn
- Understand the exact role of a Security Champion and its limits
- Choose the programme model suited to your maturity (Awareness, Activity, Hybrid)
- Recruit, train and equip your first champions without burning them out
- Structure a lasting community with regular rituals
- Measure and adjust the programme with reliable indicators and BSIMM16 benchmarks
Why does the security team not scale?
Imagine an organisation of 150 developers spread across 18 teams, with a security team of 2 people: a ratio close to 1 expert for 75 developers. Every week, these two experts receive dozens of questions, validate architecture choices, analyse SAST alerts and train newcomers.
Black Duck's BSIMM16 report (2026), which describes the software security practices of 111 organisations based on interviews and document reviews, sheds light on this imbalance. Of these 111 firms, 46 have no Security Champion, while the 65 that do have a total of 6,498. The observed ratio varies with organisation size.
| Situation | BSIMM data | What it means |
|---|---|---|
| Organisation with fewer than 650 developers | about 1 champion for 6 developers (BSIMM16) | Strong coverage, close to the teams |
| Organisation with more than 650 developers | about 1 champion for 17 developers (BSIMM16) | Natural dilution, need for stronger coordination |
| Firms with no programme | 46 out of 111 (BSIMM16) | Total dependency on the central security team |
| Top-scoring firms | 92 % have a programme (BSIMM15) | Against about a third of the bottom-scoring firms |
In this context, the security team becomes a bottleneck. It can neither answer in real time, nor validate every critical merge request, nor support each developer. Delays grow, teams work around processes to move forward, and security debt silently piles up.
The solution is not to multiply AppSec positions: qualified profiles are rare and expensive. It is to distribute expertise through a network of relays embedded in development teams, the Security Champions.
What is a Security Champion?
A Security Champion is a developer who keeps their main role while becoming the security ambassador in their team. Think of a "security correspondent": not a penetration testing expert, but someone who knows good practices, spots warning signs and handles level 1 questions without calling on the central team.
In practice, a Security Champion:
- Stays a member of their team and keeps coding
- Spends an official share of their time on security, from 5 to 30 % depending on the programme model
- Answers simple questions from colleagues ("How do I store this secret?", "This dependency has a CVE, what should I do?", a topic detailed in the vulnerability management lesson)
- Relays good practices from the central team to their team
- Escalates complex problems to the AppSec experts
The diagram shows this star-shaped (hub-and-spoke) operation: the central team trains and equips the champions, who spread the expertise and filter questions in their teams. The two-way flow brings good practices down and field alerts up.
Which programme models should you choose?
Not all Security Champions programmes look alike. Depending on your organisation's maturity and resources, three engagement levels follow one another, each with its logic and its moment: the classic mistake is aiming too high too fast. The diagram sums up the progression.
Awareness model: the starting point
The Awareness model suits organisations that are new to DevSecOps or have no established security culture yet. Champions act as information relays: they attend central training sessions, pass important alerts on to their team and answer basic questions.
The time required stays modest: 5 to 10 % of their work, at most half a day a week. Expected skills are basic: it is about knowing where to look for information rather than mastering attack techniques. This model lays the foundations without overloading volunteers.
Activity model: operational engagement
Once the culture is in place, some organisations move to the Activity model. Champions become real security actors: they take part in threat modeling sessions, do security-oriented code reviews and handle the triage of SAST and SCA alerts for their team.
This level requires 15 to 20 % of the time and intermediate skills. Champions must understand the vulnerabilities of the OWASP Top 10, know how to use analysis tools and assess the criticality of a finding (a result raised by an analysis tool). The AppSec team invests more in their continuous training.
Hybrid model: advanced maturity
The Hybrid model suits large organisations with a mature DevSecOps culture. Champions combine the activities of the two previous models and add advanced responsibilities: light penetration tests, participation in architecture decisions, contributions to internal tools and mentoring new champions.
With 20 to 30 % of their time devoted to security, these champions become technical experts in their team. Some organisations give them an official title (Security Advocate, embedded security engineer) and recognise the role in career paths.
How do you set up the programme in six steps?
Rolling out a Security Champions programme calls for a structured approach: each step prepares the next, and skipping one jeopardises the programme's durability. The journey usually takes 3 to 6 months for the first teams, then extends gradually.
-
Get executive sponsorship
Without management support, the programme stays an isolated initiative. You need three levels of support:
- An executive sponsor (CTO, CISO, VP Engineering) who legitimises the programme and allocates resources
- Team managers who agree to free up the chosen share of time
- The central security team who commits to training and supporting the champions
To convince, prepare a quantified case: shorter time to fix vulnerabilities, fewer interruptions for the AppSec team, collective upskilling. Rely on your internal data rather than generic promises.
Get a written commitment: a message from the CTO confirming the programme and the allocated time avoids later challenges.
-
Define the role precisely
Ambiguity kills Security Champions programmes. Before recruiting, document what the role involves and what it does not.
Element Description Allocated time Official percentage recognised by management (5 to 30 % depending on the model) Expected activities Concrete list of responsibilities Role boundaries The champion is not responsible for all of the team's security Available support Access to the AppSec team, training, tools, budget Recognition How the work will be valued (objectives, reviews, career path) Write an internal role description, even an informal one: it serves as a reference for recruitment and discussions with managers.
-
Recruit the first champions
Recruitment is the most critical step. A poorly chosen champion can discourage a whole team; a good one creates a ripple effect.
The criteria to look for:
- Genuine volunteering: never appoint someone by default
- Curiosity about security: interest matters more than existing expertise
- Natural influence: respected by peers, able to get messages across
- Communication skills: can explain technical concepts simply
- Real availability: the time is approved by their manager
Avoid appointing "the most senior" or "whoever has time" by default: volunteering and intrinsic motivation are the best predictors of success. For the first wave, aim for 3 to 5 pilot champions in varied teams; their feedback will shape the programme before the general rollout.
-
Train the champions
Initial training determines the champions' credibility with their teams. Plan a structured programme of 40 to 80 hours spread over 2 to 3 months:
Module Duration Content OWASP Top 10 8 h Common web vulnerabilities, concrete examples Secure development 16 h Good practices suited to the organisation's languages Threat modeling 8 h STRIDE method, hands-on exercises Internal tools 8 h SAST, DAST, SCA used in the organisation Process and escalation 8 h How to escalate, document and follow up incidents The OWASP Top 10 module relies on the 2025 edition of the list, published in its final version in January 2026: it introduces two categories, software supply chain failures and mishandling of exceptional conditions; broken access control stays at the top and security misconfiguration rises to second place. The OWASP Top 10 for DevSecOps guide details each category.
Beyond initial training, plan 4 to 8 hours of continuous training a month: a champion who does not keep up to date quickly loses relevance.
-
Structure the community
A network of isolated champions is not a programme. Create rituals that sustain engagement and foster collective learning:
Ritual Frequency Goal Champions sync Every two weeks Share concrete cases, open questions AppSec office hours Weekly Direct support from the security team Security newsletter Monthly Monitoring, news, practical advice Internal CTF Quarterly Playful upskilling, team cohesion Programme retrospective Every six months Improve how the programme works A dedicated channel for champions (Slack, Teams, Mattermost) is essential: it allows quick exchanges and resource sharing, and creates a sense of belonging.
-
Measure and improve
An unmeasured programme drifts. From the start, define the indicators described in the measurement section (coverage, engagement, time to fix, avoided escalations, satisfaction) and present them regularly to the executive sponsor: they justify the investment and guide adjustments.
What does a Security Champion's daily work look like?
Beyond theory, what does a Security Champion actually do in their week? This practical view helps calibrate expectations and prepare future champions, rhythm by rhythm.
Daily activities fit into development work with no dedicated slot:
- Answer the team's security questions ("How do I store this API key?", "Is this library safe?")
- Take part in code reviews with a security eye, without blocking the flow but flagging points of attention
- Apply good practices in their own code, which sets an example for the team
- Report anomalies spotted during ordinary development
Every week, the champion spends a few structured hours on security, ideally in a fixed slot in the calendar:
- Triage security alerts (SAST, SCA, DAST) for the team's projects
- Join the champions sync to share lessons learned
- Update local security documentation if needed
- Escalate complex questions to the central AppSec team
Monthly activities require more preparation and are planned with the tech lead:
- Continuous training on a specific topic (new vulnerability, new tool)
- Run a short awareness session for the team (30 min)
- Contribute to threat modeling of features being designed
- Review the team's security indicators with the tech lead
Quarterly activities set the rhythm of the champion's year and feed programme improvement:
- Take part in the CTF or exercise organised by the central team
- Quick assessment of the team's security maturity
- Improvement proposals for the programme drawn from the field
- Personal retrospective: what did I learn? Where should I grow?
What a Security Champion is not
Misunderstandings about the role breed frustration. Clarify these points with managers and teams from the start: a champion seen as "the security police" or "the one who says no" cannot do their job.
| Misconception | Reality |
|---|---|
| "They are responsible for all security" | Security remains a responsibility shared by the whole team |
| "They must know everything" | They know where to redirect complex questions |
| "They block releases" | They advise and inform, the team decides collectively |
| "They replace the AppSec team" | They complement and amplify the central team's work |
| "It is extra work, not recognised" | The time is officially allocated and valued |
How do you equip the champions?
A champion without tools or resources cannot fulfil their mission. The central team prepares a starter kit and maintains ongoing support, with a training budget negotiated during the sponsorship phase: a champion trained only in their personal time ends up giving up.
The starter kit
Each new champion receives a set of resources to start without improvising. The table lists the minimum; the playbook is the most useful piece in the first months.
| Resource | Description | Format |
|---|---|---|
| Playbook | Common situations and appropriate answers | Shared document |
| Code review checklist | Security points to check systematically | Markdown, merge request template |
| Tool access | SAST, DAST, SCA with permissions suited to the role | Configured accounts |
| Community channel | Space for exchanges between champions | Team messaging |
| Calendar time | Slot blocked for security activities | Calendar |
| AppSec contact | Central team referent for escalation | Named person |
The playbook saves the champion from improvising in recurring situations: "A colleague wants to use a library with a critical CVE", "QA found an XSS flaw", "The product owner asks to disable authentication for a proof of concept".
On the tooling side, champions benefit from mastering a lightweight static analyser such as Semgrep, a secrets detector such as Gitleaks, and the principles of SAST and SCA (all in French) to triage what these tools raise.
Which training path should you follow?
Initial training lays the foundations, continuous training keeps relevance. This progressive path combines a free resource and commercial platforms; volumes are orders of magnitude.
| Level | Training | Effort | Notes |
|---|---|---|---|
| Beginner | OWASP Top 10 | 8-16 h | Free, essential, 2025 edition |
| Intermediate | Secure Code Warrior | 20-40 h | Playful, adapted to the language |
| Advanced | AppSecEngineer | 40-80 h | Complete DevSecOps path |
Certifications are not essential, but they value the path of the most engaged champions. The efforts shown are preparation estimates, to adjust to each profile.
| Certification | Topic | Estimated effort |
|---|---|---|
| CSSLP (ISC2) | Secure software lifecycle | ~200 h |
| CEH (EC-Council) | Ethical hacking | ~120 h |
| CDP (Practical DevSecOps) | Certified DevSecOps Professional | ~80 h |
The page on team training (in French) extends this approach beyond champions alone.
Which traps should you avoid?
Many Security Champions programmes do not survive their first year. The mistakes that make them fail come back from one organisation to another; knowing them lets you avoid them from the design stage.
Ghost time
Management approves the programme "in principle" but never frees up the champions' time. They have to choose between their deliverables and their security activities, and security loses every time. The fix: a written commitment with a precise percentage, champion activities included in individual objectives, and a monthly check with managers on the actual allocation.
Forced appointment
To go fast, managers appoint "champions" without asking for their opinion. These unwilling champions have neither motivation nor legitimacy, and the team sees them as imposed inspectors. The fix: communicate widely about the programme, hold information sessions, let volunteers come forward, and accept that some teams will not have a champion straight away.
Isolated champions
Trained at the start and then left on their own, champions pile up unanswered questions and lose confidence; the team stops asking them. The fix: weekly office hours, an active channel, and a maximum response time of 24 h to champions' questions.
Lack of recognition
Champion work stays invisible in reviews: colleagues get promoted thanks to visible features, the security contribution goes unnoticed. The fix: include the role in evaluation criteria, publicly value contributions, and create a visible progression path.
Excessive ambition
Excited by the concept, the programme starts straight at the Hybrid model: 30 % of the time, systematic threat modeling, penetration tests, training. Champions burn out and give up. The fix: start with the Awareness model, only progress on solid foundations, and measure engagement before adding responsibilities.
How do you measure the programme's success?
A Security Champions programme is a significant investment: champions' time, training, tooling, facilitation. Indicators justify it and reveal areas for improvement; the security KPIs lesson places them within overall security steering.
Quantitative indicators
Five indicators are enough to steer a programme. The targets in the table are starting benchmarks to adapt to your context, not published standards: the trend matters more than the absolute value.
| KPI | Formula | Indicative target | Interpretation |
|---|---|---|---|
| Coverage | Teams with an active champion / total teams | > 80 % | Programme rollout |
| Engagement | Champions attending syncs / total champions | > 80 % | Community vitality |
| Time to fix | Median time to fix vulnerabilities | decreasing against the baseline | Operational impact |
| Avoided escalations | Questions solved locally / total questions | > 70 % | Filtering effectiveness |
| Satisfaction | Quarterly survey of the champions | increasing | Programme quality |
Measure these indicators every month in the first year, then every quarter once the programme is stable. Also track the champions' own satisfaction, not just their activity: a burnt-out champion leaves the programme before activity figures drop.
Qualitative signals
Beyond the figures, some behaviours signal a programme that works. They show up in daily exchanges and retrospectives more than on a dashboard:
- Developers ask security questions before coding, not after deployment
- Vulnerabilities are detected earlier in the development cycle
- The AppSec team gets fewer basic questions and focuses on complex topics
- Champions stay engaged beyond the first year
- Other developers spontaneously ask to join the programme
The six-monthly retrospective
Every six months, a retrospective brings champions and the AppSec team together around four questions: what works and should be reinforced, what frustrates, what is missing, and is the programme ready to move to the next model? It keeps the programme alive and in tune with the field.
Key points
- A Security Champions programme distributes security expertise into development teams rather than concentrating it in an overwhelmed central team.
- The BSIMM16 report (2026) measures a ratio of about 1 champion for 6 developers below 650 developers and 1 for 17 above; 46 of the 111 firms have no champion.
- Start with the Awareness model (5 to 10 % of the time) before considering Activity then Hybrid.
- Genuine volunteering is the best predictor of success, never a forced appointment.
- Written executive sponsorship, with an officially allocated share of time, avoids the "ghost time" trap.
- Initial training (40 to 80 h) covers the OWASP Top 10:2025, secure development, STRIDE threat modeling and internal tools.
- A living community (regular syncs, AppSec office hours, dedicated channel) prevents champions from becoming isolated.
- Measure coverage, engagement, time to fix and satisfaction: an unmeasured programme silently drifts.
Knowledge check
Check that you have the essentials of this guide. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Training teams in security: a complete programme
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
The questions below cover the most frequent doubts about Security Champions: the difference with an AppSec engineer, the ratio to aim for, recruitment, the time to devote and training.
External resources
The OWASP guide remains the reference to structure a programme, the open source playbook provides ready-to-use templates, and the BSIMM report gives the figures quoted on this page.