Security Champions: How to Build a Developer Security Programme That Scales

The ratio problem in application security is consistent across organisations of a certain size: one or two security practitioners serving an engineering team of twenty or more developers. At that ratio, security cannot review every pull request, attend every design session, or be consulted on every decision. The options are to accept that most development work happens without security input, to slow down engineering by routing everything through a bottleneck, or to distribute security knowledge into the engineering team itself. The security champions model is the third option.

A security champion is a developer who takes on additional security responsibilities within their team. They are not a security engineer. They are still primarily a developer. The role is to act as a first point of contact for security questions within their team, to participate in security reviews, and to stay current enough on application security that they can catch common issues before they reach the security team. Done well, this multiplies the effective security capacity of a small security function without requiring additional headcount.

Selecting the Right People

The most common mistake in security champions programmes is making participation mandatory or selecting people based on seniority rather than interest. A mandatory champion who does not want the role will do the minimum required and provide no actual value. An interested developer at any level who genuinely cares about security will be far more effective. Selection should be voluntary, and the programme should be attractive enough that developers want to participate.

What makes a good security champion is curiosity about how things can break, enough patience to read security documentation and pen test reports, and sufficient communication skills to translate security concepts for their team. Some of the best champions we have seen come from developers who were personally affected by a security incident or who had an interesting finding in a pen test and wanted to understand it more deeply. Previous security knowledge is useful but not required: the programme should build it.

What the Programme Actually Involves

A functional security champions programme has three components: regular training, a community of practice, and meaningful responsibilities. Training should be practical rather than theoretical. Working through real vulnerabilities from your own pen test findings is more effective than generic online courses, because champions can see how the issue appeared in their own codebase and what the fix looked like. Pair each training session with a concrete example from your own security testing history.

The community of practice is a regular meeting, typically monthly, where champions share what they have been seeing, discuss new vulnerability types, and work through case studies together. This is where the programme develops its own momentum. Champions who are only trained in isolation and never interact with each other do not build the shared knowledge base that makes the model effective. The meeting does not need to be long: 45 minutes of focused discussion is more valuable than a two-hour lecture.

Giving Champions Meaningful Responsibilities

Champions need responsibilities that are real, not ceremonial. Common effective responsibilities include: participating in design reviews for significant features, reviewing pull requests for security-sensitive code, being the first escalation point for security questions from their team, and contributing to the organisation's security documentation. These are tasks that genuinely benefit from someone with developer context and security knowledge, rather than tasks created to justify the programme's existence.

Avoid overloading champions. The role is additional to their normal development work, not a replacement for it. If a champion is spending more than a few hours per week on security responsibilities, either the scope of the programme is too broad for the champion's time, or the organisation needs a dedicated security engineer rather than a champion model. Champions work best as a scaling mechanism for a security function that already exists, not as a substitute for security expertise the organisation does not have.

Measuring Whether the Programme Is Working

The primary measure of a security champions programme is whether security issues are being caught earlier in the development process. Track where security findings originate: design review, code review, automated scanning, internal testing, or external pen test. A working champions programme shifts findings earlier in that sequence. More findings caught in code review means fewer findings in the pen test, which means lower remediation cost.

Secondary measures include the number of security questions that champions resolve without escalating to the security team, champion retention rate, and developer satisfaction with security support. High escalation rates suggest champions need more training. Low retention suggests the role is not valued or is too burdensome. Developer satisfaction with security support is a leading indicator of whether engineers are engaging with security processes or routing around them.

• Select champions based on interest, not seniority or obligation
• Use your own pen test findings as training material
• Run a monthly community of practice meeting, not just individual training
• Give champions real responsibilities in design and code review
• Cap champion time commitment to avoid burning out good people
• Track where findings originate to measure the programme's effect

We help engineering organisations design and launch security champions programmes, including building training curricula from their own pen test history. If this is something you are exploring, reach out at info@cyberlinx.com.au.