A security champion is a member of the development team who acts as a liaison between information security and development – according to OWASP SAMM, this can be a software developer, tester, or product manager. Typical responsibilities include researching, verifying, and prioritizing security-relevant defects, contributing to risk, threat modeling, and architecture assessments, and conducting regular security-focused reviews within their own team. The NIST Secure Software Development Framework (SP 800-218, Version 1.1) also mentions security champions in its implementation examples – as an SDLC role to be defined (PO.2.1) and as a preferred audience for threat modeling training (PW.1.1). Champions do not replace a central AppSec team; they scale its impact across the organization.
Security Champions in Software Development
How to embed security expertise in your development teams for the long term – from selecting suitable champions through time budgets and community to measuring success based on the OWASP guide and SAMM.
A central application security team cannot possibly accompany every code review, every threat modeling session, and every architecture decision across all development teams. Security champions programs address this scaling problem by embedding security knowledge and responsibility directly within the teams: one member per team takes on – with a dedicated time budget – the role of liaison to information security. With the OWASP Security Champions Guide and the OWASP SAMM maturity model, two freely available references exist that structure the setup and continuous development of such programs. What ultimately determines success, however, is less the frameworks than the surrounding conditions: voluntary participation, management backing, community, and measurable goals.
The Essentials at a Glance
Six topic blocks — tap to expand.
Program Building Blocks
Four building blocks of a security champions program — from the role to measuring success. Tap a tab for details.
- A security champion is a member of the development team and liaison to information security — according to OWASP SAMM, this can be a software developer, tester, or product manager.
- Typical responsibilities: researching, verifying, and prioritizing security-relevant defects; contributing to risk, threat modeling, and architecture assessments; regular security-focused reviews within their own team.
- NIST SP 800-218 (Version 1.1) also mentions champions in its implementation examples — as an SDLC role to be defined (PO.2.1) and preferred audience for threat modeling training (PW.1.1); they do not replace a central AppSec team.
- The OWASP Developer Guide advises against arbitrary appointments: motivated team members should volunteer — “Be passionate about security” is the manifesto's first principle.
- Since champions keep their primary role, the additional responsibility needs a formally committed time budget; SAMM provides for a fixed number of hours per week without prescribing a specific value.
- Proven in practice: one champion per development team plus a dedicated program lead (“captain”); without visible management backing, experience shows the time budget is the first thing sacrificed under project pressure.
- “Create a community” and “Promote knowledge sharing”: regular meet-ups, shared communication channels, and internal workshops across team boundaries.
- “Reward responsibility”: formal recognition such as awards or badges, budget for training and conferences, career paths, and expanded mandates such as participation in security committees — tailored to individual motivations.
- If the additional responsibility is not visibly rewarded, the volunteers' motivation erodes over time.
- The OWASP guide recommends measurable goals: hours spent on security per champion, training goals achieved, the number of meet-ups, and risk reduction — plus team coverage and vulnerabilities found early in development.
- Common mistakes: champions as a fig leaf without a mandate, a missing or merely informal time budget, appointment by decree, a community that falls dormant after the kick-off, and a lack of succession planning.
- SAFECode emphasizes: merely naming a champion without a formalized, management-backed program usually meets resistance or fails entirely.
Standards & Sources
The content on this page is based on the following publicly available guides and studies.
OWASP Security Champions Guide
Vendor-neutral guide (incubator project) featuring the Security Champions Manifesto and ten principles, based on interviews with AppSec leaders worldwide; continuously maintained (as of July 2026).
OWASP SAMM – Education & Guidance, Stream B: Organization and Culture
Anchors security champions as a maturity level 1 activity (one champion per team, fixed weekly hour allocation); current model version 2.2.0 (July 2025).
OWASP Developer Guide – Security champions program
Continuously maintained online chapter (as of July 2026); recommends self-selection of motivated team members over arbitrary appointment and describes typical champion responsibilities.
NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1
Mentions security champions in the implementation examples for PO.2.1 (defining SDLC roles) and PW.1.1 (threat modeling training).
Software Security Takes a Champion
Practical guide by the SAFECode industry initiative on the role and responsibilities of champions and on the need for a formalized, management-backed program.
Building or revitalizing a security champions program?
We support you in designing your program along the OWASP guide and SAMM – from selecting champions through secure coding training to measuring success. Schedule a no-obligation initial consultation.