Scaling Security Culture: Why Your Security Champion Program is Failing

TLDR: Most security champion programs fail because they treat diverse engineering teams as a monolith, ignoring the underlying organizational culture. By categorizing champions into four distinct archetypes—Sentinels, Apprentices, Learners, and the Fan Club—you can tailor your engagement and metrics to match the team's actual workflow. This shift moves security from a top-down mandate to a distributed, sustainable practice that actually sticks.

Security champion programs are the industry's favorite way to offload the impossible task of scaling security across hundreds of engineering teams. We hire a few security engineers, give them a budget for stickers, and expect them to magically transform developers into security experts. Then, six months later, we wonder why the program is dead, the "champions" are burnt out, and the same vulnerabilities keep appearing in production. The problem isn't the developers. The problem is that we are trying to force a single, rigid framework onto teams that operate with fundamentally different priorities and risk tolerances.

The Four Tribes of Security Champions

Successful programs recognize that security is not a one-size-fits-all endeavor. You cannot apply the same engagement model to a high-velocity product team that you apply to a legacy infrastructure team. Marisa Fagan’s research at Security BSides 2025 highlights that security champions naturally fall into four distinct archetypes. Understanding which tribe your teams belong to is the first step toward building a program that doesn't just exist on paper.

The Sentinels are your high-stakes, high-engagement group. They are often found in teams handling critical infrastructure or sensitive data. They don't just care about security; they are actively involved in threat modeling and mandatory certification processes. If you are running a zero-trust rollout, these are the people you want in the room. They are the early adopters who will help you beta test new security controls before they hit the wider organization.

The Apprentices are the backbone of your application security efforts. These are developers who have been nominated by their managers to take on security responsibilities. They are the ones actually running the OWASP Top 10 checks during the sprint. They need clear, actionable guidance and a direct line to the security team when they hit a wall. If your program doesn't provide them with a clear path to resolve vulnerabilities, they will stop participating.

The Learners are your grassroots movement. They are volunteers who join because they want to level up their own skills. They aren't necessarily looking to become full-time security engineers, but they are interested in CTFs, brown-bag sessions, and knowledge sharing. They are the most resilient part of your program because their motivation is internal.

Finally, the Fan Club is exactly what it sounds like. These are the people who show up for the free food and the stickers. While it is easy to dismiss them, they are vital for building a "see something, say something" culture. They provide the broad, company-wide awareness that prevents the most basic phishing and social engineering attacks.

Aligning Culture with Strategy

Most security teams make the mistake of trying to turn everyone into a Sentinel. This is a recipe for disaster. If you try to force a team that is focused on rapid feature delivery to adopt the rigorous, documentation-heavy processes of a Sentinel team, you will create friction. That friction is the enemy of security.

Instead, look at your organizational culture through the lens of Lance Hayden’s Security Culture Framework. Are you in a compliance-heavy environment where "tight control" is the only language that works? Or are you in a high-autonomy, "cowboy" culture where security must be invisible to be adopted?

If you are in a high-autonomy environment, stop trying to mandate security training. It won't work. Instead, build a community where security is a competitive game. Use Splunk or other SIEM tools to track security events and reward the teams that catch the most anomalies. If you are in a compliance-heavy environment, focus on integrating security into the existing audit workflow. Make the "secure way" the "easy way" to pass the audit.

Measuring What Matters

Stop measuring the number of security champions you have. That is a vanity metric. It tells you nothing about your actual risk. Instead, measure the impact of your champions on the development lifecycle.

If you have a group of Apprentices, measure the time-to-remediation for vulnerabilities in their specific services. If you have a group of Sentinels, measure the number of threats identified during the design phase, before a single line of code is written. If you are focusing on the Fan Club, measure the reporting rate for phishing simulations.

When you align your metrics with the specific tribe, you stop fighting the culture and start working with it. You will find that the "resistance" you thought you were facing was actually just a mismatch in expectations.

The Path Forward

Building a security champion program is not about finding the perfect framework. It is about the hard, unglamorous work of talking to people, understanding their pain points, and finding the intersection between their goals and your security requirements.

If you want to see what a mature program looks like, look at the OWASP Security Champions Guide. It is a living document, and it is the best resource we have for moving beyond the "sticker-and-pizza" phase of security culture. Stop looking for a silver bullet. Start by identifying which of the four tribes your teams belong to, and then build a program that actually helps them do their jobs better. The real framework isn't a slide deck; it's the relationships you build with the people who are actually shipping the code.