Skip to content
Back to blog
DevSecOps

Building a Security Champions Program

How to scale security practices across engineering teams without a large dedicated security headcount, using a champions model that actually works.

S
SecureScout Team· Security Engineering
July 23, 20265 min read

Most engineering organizations can't afford a security engineer embedded on every team. A security champions program is how you get the benefit of that embedded presence without the headcount.

What the role actually is

A security champion is an engineer who remains on their existing team, doing their existing job, with a protected slice of time (commonly 10-20%) dedicated to security-related work: reviewing PRs with a security lens, triaging findings from scanners, and being the first point of contact between their team and the central security function.

Why this model works better than centralization

A small central security team simply can't review every PR or answer every "is this safe" question across a growing engineering org without becoming a bottleneck. Champions distribute that context across teams, so security questions get answered by someone with both security awareness and deep knowledge of that specific team's codebase.

What makes a program actually succeed

  • Protected time, not "extra" work. If champion responsibilities are purely additive to a full workload, they get deprioritized under any deadline pressure.
  • Real training, not just a title. Champions need actual security education — threat modeling, common vulnerability classes, how to use your scanning tools — not just a Slack channel added to their name.
  • A feedback loop with the central security team. Champions should surface patterns they see across their team back to security, not just consume guidance one-way.
  • Recognition that's visible. Promotions, performance review credit, or public recognition for champions' work signals the role is taken seriously, not a volunteer add-on.

Common failure modes

The most common way these programs fail is treating them as a one-time kickoff — a announcement, a Slack channel, then no ongoing structure. A program that survives past the first quarter has a regular cadence (monthly sync, shared metrics, updated training) keeping it alive.

Measuring impact

Track things like time-to-fix for security findings on teams with an active champion versus without, and how often champions catch issues before they reach the central security team. If there's no measurable difference, the program needs structural changes, not just more champions.

security-culturedevsecopsteam-building

Frequently Asked Questions

Should security champions be full-time security roles?

No — the model works precisely because champions remain embedded engineers on their team, spending a modest, protected amount of time (often 10-20%) on security work, not full-time security hires.

How many champions do we need?

One per team or squad is a reasonable starting point. The goal is having someone with security context close to every set of day-to-day engineering decisions, not centralizing that context in one place.

Related Articles

S

SecureScout Team

Security Engineering

Learn more →