Central security teams cannot review every design, pull request and pipeline change, so security knowledge has to live inside the delivery teams themselves. A security champions programme puts a trained, recognised person in each team who acts as the link to the security function, raises risks early and helps colleagues fix them. Many programmes start with enthusiasm and fade within a year because time, mandate and recognition were never agreed. This guide covers how to design, launch, run and measure a champions programme, drawing on the OWASP Security Champions Guide, OWASP SAMM and NIST SSDF. It is written for application security leads, engineering managers and CISOs, with notes for executives who must fund it.
Key takeaways
- A champion is a liaison, not a substitute security team. OWASP SAMM describes the champion as the link between information security and developers, with a set number of hours each week for security work.
- Formal time and management backing decide success. The OWASP guide warns that when priorities conflict, formalised priorities win, so the programme needs approval from engineering and security leadership.
- Someone must run it full time. OWASP's interviews found that leading a programme is a full-time job, and a small team in larger organisations.
- Recruit volunteers and invest in them. Passion, training budget, recognition and a career path keep champions engaged; assigned, unrewarded champions drift away.
- Plan for people leaving. Group champions by specialism, keep a sensible ratio and run continuous onboarding so one departure does not break coverage.
What a security champion is, and is not
OWASP SAMM's Education and Guidance practice places "Identify a 'Security Champion' within each development team" at maturity level 1 of its Organization and Culture stream. SAMM describes the role in some detail:
- Who: depending on team size and structure, a software developer, tester or product manager.
- Time: a set number of hours per week for information security activities.
- Learning: periodic briefings across security disciplines and additional training to develop subject-matter expertise.
- Work: researching, verifying and prioritising security and compliance defects; taking part in risk assessments, threat assessments and architecture reviews; giving the team periodic reviews of open security issues.
A champion is not a part-time penetration tester, a compliance officer or the person who signs off releases alone. The security team keeps ownership of policy, specialist testing and risk acceptance above the agreed threshold. The OWASP guide frames the vision as democratising security knowledge in development teams, reducing dependency on the central team and governing security within those teams. Champions are also not limited to software: the same model works in infrastructure, data, cloud platform and IT operations teams.
The ten OWASP principles in practice
The OWASP Security Champions Guide is organised around ten principles. The table summarises each one and what it means in a real programme.
| OWASP principle | What it asks for | Practical decision |
|---|---|---|
| 1. Be passionate about security | Recruit volunteers, avoid assigning champions where possible, keep curiosity alive | Open call for volunteers with manager agreement; ask about security in hiring |
| 2. Start with a clear vision for your program | A vision that is imaginable, desirable, feasible, focused and communicable | One-page operating model showing champion, engineer, lead, product owner and security roles |
| 3. Secure management support | Formal approval from the head of IT or engineering and the security leader, with HR involved | Charter signed by engineering and security leadership |
| 4. Nominate a dedicated captain | A dedicated leader for strategy, roadmap, community and reporting | Full-time programme lead, a small team in large organisations |
| 5. Trust your champions | Clear mandate, freedom to experiment, involvement in security team processes | Champions may decide on risks within the organisation's risk appetite |
| 6. Create a community | Purpose, channels, events and measurable success criteria | Chat channel, monthly meet-up, quarterly in-person or virtual event |
| 7. Promote knowledge sharing | Formal and informal learning, rotating speakers, gamification | Lunch sessions, capture the flag events, internal talks by champions |
| 8. Reward responsibility | Tangible and intangible recognition tailored to individuals | Awards, conference sponsorship, development plans, extended privileges for milestones |
| 9. Invest in your champions | Formally allocated time, training budget, job titles, bonuses or promotion | Time allocation written into team capacity plans |
| 10. Anticipate personnel changes | Continuity through ratios, training pipelines and official recognition | Specialist pools rather than a single champion per team |
Designing the programme
Scope and operating model
- Teams in scope: start with teams that build or run systems handling sensitive data or internet-facing services, then expand.
- Coverage model: one champion per team is simple to explain but fragile. OWASP recommends against a strict one-champion-one-team model and suggests pools grouped by specialism (for example container security or API security) so knowledge survives departures. For large organisations it gives an example ratio of one champion per 25 developers.
- Mandate: write down what champions may decide (for example, accepting low-severity findings within policy, approving use of a vetted library) and what must escalate to the security team.
- Time: agree a fixed allocation with engineering managers and record it in capacity planning. SAMM calls for a set number of hours per week; the exact figure is a local decision, so state it in the charter and measure against it.
Responsibilities across the lifecycle
| Lifecycle stage | Champion activity | Security team activity |
|---|---|---|
| Requirements | Raises security requirements and abuse cases in refinement | Maintains requirement catalogues and standards |
| Design | Leads or joins threat modelling sessions (SAMM lists champions as participants) | Facilitates high-risk threat models, reviews outcomes |
| Build | Reviews security-relevant changes, helps tune scanners for the team | Owns tool selection and central rules |
| Test | Triages and prioritises findings with the team | Runs specialist testing and penetration tests |
| Release and operate | Checks secrets, dependencies and configuration hygiene | Monitors, responds to incidents, handles disclosure |
| Learn | Shares lessons from findings and incidents with the team and community | Feeds threat intelligence and incident lessons to champions |
See the Security Requirements and Abuse Cases Guide, the Threat Modelling Guide and the Secure Code Review Guide for the techniques champions use most.
Onboarding security champions
Onboarding is where most programmes either build confidence or lose people. A structured first 90 days works better than a single training course.
- Agreement: the champion, their manager and the programme lead sign a short role agreement covering time allocation, mandate and expectations.
- Orientation (weeks 1 to 2): meet the security team, learn the escalation routes, the secure development standard, the vulnerability management SLAs and the tools the team uses.
- Foundation training (weeks 2 to 6): role-based training on common vulnerability classes for the team's stack, threat modelling basics and secure code review. NIST SP 800-218 task PO.2.2 calls for role-based training for all personnel whose responsibilities contribute to secure development.
- Shadowing (weeks 4 to 8): join a threat model and a triage session led by the security team or an experienced champion.
- First contribution (by week 12): lead one activity for their own team, for example a threat model for a new feature or a scanner tuning exercise, with support.
- Development plan: agree a personal development plan, which OWASP lists among its reward artefacts, and set the next learning goal.
To test the onboarding path, pilot it with a small cohort of volunteer champions, collect feedback after each stage and adjust before wider rollout. If a cohort struggles, pause new intake rather than lowering the bar.
Rolling out the programme
- Baseline: assess current practice, for example with OWASP SAMM, and record the metrics you intend to improve.
- Vision and charter: draft the vision with engineering leads, product owners and senior developers, as OWASP advises, then get it approved by engineering and security leadership and HR. NIST SSDF task PO.2.3 calls for upper management commitment to secure development, conveyed to everyone with development roles.
- Appoint the lead: name or hire the dedicated programme lead before recruiting champions.
- Pilot: start with three to five teams that volunteer. Run onboarding, community events and metrics for one or two quarters.
- Review: compare pilot teams with the baseline, gather champion and manager feedback, and fix the operating model.
- Expand in waves: add teams by risk, keeping the champion-to-developer ratio and the lead's capacity in view.
- Roll back safely: if a wave overwhelms the programme lead or champions report no protected time, stop expanding, restore the allocation and resume once capacity is fixed. A stalled programme is better than a nominal one that teams stop trusting.
SAMM shows the path beyond champions: level 2 is a secure software centre of excellence with an official charter, and level 3 is a security community open to everyone involved in software security, which in turn helps identify future champions.
Decision guidance: choosing a model
| Model | Best for | Trade-offs |
|---|---|---|
| One champion per team | Small organisations, fewer than about ten teams | Simple, clear ownership; fragile when people leave |
| Specialist pools (OWASP's suggested pattern) | Large organisations with varied stacks | Resilient and deep in each topic; needs good routing so teams know whom to ask |
| Hybrid: team champion plus specialist pools | Organisations scaling past a few hundred engineers | Best coverage; more coordination for the programme lead |
| Embedded security engineers instead of champions | Highest-risk platforms where full-time security staff are justified | Expensive; does not build security skills across the wider team on its own |
Small organisations can run a lightweight version with a part-time lead, a monthly session and a shared channel, but they should still write the role agreement and protect time. Large organisations should expect to need a small programme team and HR involvement for job titles, recognition and recruitment.
Running the community and keeping champions engaged
The OWASP guide treats community, knowledge sharing, reward and investment as four separate principles, which reflects how much effort they take after launch. A workable annual rhythm looks like this:
- Weekly: an open chat channel where champions ask questions and the security team answers within an agreed time. Track unanswered questions; slow answers are an early sign the security team is under-resourced.
- Monthly: a community session with a short talk from a champion or the security team, a review of recent findings or incidents, and one practical exercise. Rotate speakers and topics, as OWASP advises, so sessions stay relevant to daily work.
- Quarterly: a capture the flag event, hackathon or deeper workshop, and a metrics review with sponsors.
- Annually: recognition awards, renewal of role agreements, refresh of the curriculum against the organisation's main vulnerability classes, and a programme reassessment against SAMM.
Feed champions what the security team learns: threat intelligence relevant to their stack, lessons from incidents and penetration tests, and early notice of new standards. OWASP's trust principle also asks the security team to involve champions in its own processes and to seek their input on policies, so treat champions as a review panel for new standards before they are published. Recognition should be visible to managers and HR, because a champion's work otherwise rarely appears in performance reviews. OWASP suggests milestone badges that unlock extended privileges, such as a mandate to review specific policies or decide on specific risks, which rewards growth with responsibility rather than only with gifts.
Where identity fits
Champions are often the first to see how a team handles credentials: API keys in configuration files, shared service accounts, long-lived tokens in pipelines. Make secrets and non-human identity hygiene part of the champion curriculum, and route secret-scanning alerts to the team's champion as well as to security. In the xAI API key leak, an automated scanner alert reached the developer who committed the key, but the key stayed valid for about two months until a public report reached the security team. See the Application Security Guide and the DevSecOps Guide.
Detection and measurement
OWASP's vision principle suggests goals such as hours spent on security by champions, training objectives, number of meet-ups and reduction in security risk. Measure activity and outcome together, and report to the sponsors quarterly.
| Metric | What it shows | Source |
|---|---|---|
| Coverage: percentage of in-scope teams with an active champion or pool | Reach of the programme | Programme register |
| Protected time used versus agreed | Whether the allocation is real | Champion self-report, capacity tools |
| Threat models completed for new features in champion teams | Earlier security involvement | Threat modelling records |
| Median time to remediate high and critical findings, champion versus non-champion teams | Effect on risk | Vulnerability management platform |
| Champion retention after 12 months | Health and sustainability | Programme register, HR |
| Onboarding completion within 90 days | Onboarding quality | Learning platform |
Avoid counting only attendance or training hours: they show activity, not whether teams ship fewer or less severe vulnerabilities. Compare like with like, since champions often volunteer from already mature teams.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| OWASP SAMM | Governance: Education and Guidance, Organization and Culture stream | Level 1 identify champions; level 2 centre of excellence; level 3 security community |
| NIST SP 800-218 (SSDF) | PO.2.1, PO.2.2, PO.2.3 | Define SDLC roles, role-based training, management commitment |
| NIST CSF 2.0 | GV.RR-02, GV.RR-04, PR.AT-01, PR.AT-02 | Roles and authorities; security in HR practices; general and specialised training |
| NIST SP 800-53 Rev. 5 | AT-2, AT-3, PM-13, SA-3, SA-8, SA-15 | Awareness and role-based training, security workforce, SDLC, engineering principles, development process |
| UK Software Security Code of Practice | Principle 1.1 and the Senior Responsible Owner and skills expectations | Secure development framework including governance and roles; leaders ensure teams have skills |
| CIS Controls v8.1 | Control 16 Application Software Security | Managing the security life cycle of in-house developed software, including developer training |
Common failure patterns
- No protected time: champions are named but their delivery targets are unchanged, so security work happens only in spare moments and stops under deadline pressure.
- Volunteers by decree: managers assign the most junior person, who has neither interest nor influence; OWASP advises recruiting volunteers wherever possible.
- Programme run on the side: a busy security engineer runs it alongside other work and momentum collapses after launch.
- Champions as unpaid gatekeepers: champions are made to sign off releases without authority or support, and teams start to route around them.
- Single points of failure: one champion per team with no pool or successor, so coverage disappears when they move on.
- Alerts that go nowhere: scanner and secret alerts reach individuals but not the champion or security team, as the xAI case above shows.
Practitioner checklist
- Charter approved by engineering and security leadership, with HR involved for role recognition.
- Named, dedicated programme lead in post before recruitment starts.
- Written role agreement for each champion: time allocation, mandate and escalation routes.
- 90-day onboarding path with role-based training and a first supported contribution.
- Community channel, regular meet-ups and a calendar of knowledge-sharing sessions.
- Recognition scheme and training budget agreed for the year.
- Specialist pools or successors so no team depends on one person.
- Quarterly metrics on coverage, protected time, remediation time and retention reported to sponsors.
- Secrets and credential hygiene included in the champion curriculum, with alerts routed to champions.
Standards and references
- OWASP: Security Champions Guide
- OWASP: SAMM Education and Guidance
- NIST: SP 800-218 Secure Software Development Framework
- DSIT and NCSC: Software Security Code of Practice
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- CIS: Control 16 Application Software Security
- OWASP: Security Champions Guide project
Related NHI Mgmt Group resources: Secure Software Development Lifecycle (SSDLC) Guide · Security Awareness and Human Risk Management Guide · Application Security Guide · DevSecOps Guide