01Role and Responsibilities: Multiplier, Not a Replacement for the AppSec Team
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.
02Selection and Time Budget: The Foundation of the Program
The OWASP Developer Guide advises against arbitrary appointments: the role requires genuine interest in application security, which is why motivated team members should volunteer – it is no coincidence that the first principle of the OWASP manifesto reads “Be passionate about security”. Since champions keep their primary role, the additional responsibility needs a formally committed time budget; OWASP SAMM explicitly provides for a fixed number of hours per week for security activities without prescribing a specific value. One champion per development team and a dedicated program lead (“captain”) responsible for vision, onboarding, and coordination have proven effective. Without visible management backing (“Secure management support”), experience shows the time budget is the first thing sacrificed under project pressure.
03Community of Practice and Incentives
Champions deliver lasting impact when they do not work in isolation but within a community of practice: the OWASP guide's principles “Create a community” and “Promote knowledge sharing” recommend regular meet-ups, shared communication channels, and internal workshops across team boundaries. For incentives, “Reward responsibility” applies: formal recognition (such as awards or badges), budget for training and conferences, career paths, and expanded mandates such as participation in security committees – tailored, as the guide recommends, to each champion's individual motivations. What matters is that the additional responsibility is visibly rewarded; otherwise, the volunteers' motivation erodes over time.
04Orientation: The OWASP Security Champions Guide
The OWASP Security Champions Guide (currently an OWASP incubator project) is an open, vendor-neutral reference based on interviews with AppSec leaders, program coordinators, and champions from a range of industries and company sizes. At its core is the Security Champions Manifesto with ten principles – from “Be passionate about security” through “Start with a clear vision for your program”, “Nominate a dedicated captain”, and “Trust your champions” to “Anticipate personnel changes”. The guide explicitly positions itself as a toolbox: there is no single model that fits every organization; for each principle it provides explanations and adaptable artifacts for your own program.
05Positioning in the Maturity Model: SAMM Education & Guidance
In the OWASP Software Assurance Maturity Model (SAMM, current model version 2.2.0 from July 2025), security champions are anchored in the “Organization and Culture” stream of the Education & Guidance practice (Governance business function). Maturity level 1 requires identifying a champion in every development team and granting them a fixed weekly hour allocation; level 2 adds a Secure Software Center of Excellence composed of architects and senior developers from different business units; level 3 establishes organization-wide platforms for knowledge sharing. A champions program can thus not only be built, but also objectively positioned and incrementally advanced as part of a SAMM assessment.
06Measuring Success and Common Pitfalls
The OWASP guide recommends underpinning the program vision with measurable goals, citing as examples the hours spent on security per champion, training goals achieved, the number of champions meet-ups, and the reduction of security risk; team coverage and vulnerabilities found early in the development process are useful additions. The most common mistakes mirror the principles: champions as a fig leaf without a mandate, a missing or merely informal time budget, appointment by decree instead of voluntary participation, a community that falls dormant after the kick-off, and a lack of succession planning for personnel changes. SAFECode explicitly emphasizes that merely naming a champion without a formalized, management-backed program usually meets resistance or fails entirely.