Note from the authorThe security champions program is one of the best ideas product security ever produced, and one of the most reliably disappointing. Almost every team has tried a version of it. Almost none will tell you it worked the way they hoped.
I brought that question, why the gap is so consistent, to James Berthoty, founder and analyst at Latio, who has built three of these programs himself and studied many more from the outside. Between us we have watched dozens, from the whiteboard optimism of the first month to the slow silence of the sixth, and more recently watched a few evolve into something almost entirely agentic. What follows is the argument that came out of that conversation: why the idea was sound, why so many programs quietly die, and what AI genuinely changes, including the parts it leaves exactly as broken as it found them.
Security champion programs were never about managing tickets
The idea started as arithmetic. One security engineer for every hundred developers, often worse. At that ratio nobody reviews every design decision, every code change, every deployment. Something has to give, and for years the answer was the security champion: an engineer on each team who carries security into the rooms security can’t be in.
The vision was generous. A security champion who understands their application’s architecture, spots risk while a feature is still being drawn, escalates what matters, and lifts the whole team’s baseline. Not a ticket-closer. An owner. And the highest-leverage item on that list was always the earliest one, catching risk at design time, before a line of code exists. It is also the hardest to scale and the easiest to skip. That is the tell. The security champion program was never about managing tickets. It was about security ownership, developers owning the outcome end to end.
Why most of them quietly die
Most security champion programs fail. Not loudly, and not because developers refuse to help. They fail because nobody funded the ownership, and an unfunded program dies on a schedule.
The pattern repeats. No budgeted time, so participation is unpaid work bolted onto a sprint, running on personal motivation until the motivation runs out. No clear owner, so nobody tracks it, and it goes quiet a few months in. No credit, so momentum stalls. No guidance, so the champion cannot separate the change that matters from the dependency bump that doesn’t, and everything looks urgent until nothing does.
Underneath all four is a misread of what the tooling ever did. Scanners are work-generation machines. You buy one to discover a thousand problems, and the discovery was always the easy part; the fixing was always going to be yours. So teams wire up the scanners, watch the flood arrive, and stand up a security champions program to bail it out. The program becomes a drain for issues that were surfaced with no plan to resolve them.
The fix is unglamorous to the point of boring. Stop routing security work around the way developers already earn credit. No leaderboard, no swag, no pizza party. Put the finding in as a ticket with story points, prioritized and assigned like every other piece of work, so it lands inside the incentives the developer is already measured on. It is not clever. It works.
Blocking, the reflex the industry reaches for first, tends to do the opposite of what it promises. Block a build over a stale framework, and the developer who only wanted to recolor a button can no longer ship, the service stops pulling its own updates, and your posture quietly gets worse. You have stopped the work and degraded the security, both in security’s name.
What is left when the funding never comes is easy to recognize. A Slack channel. A wiki nobody opens. A metric that counts meetings instead of risk.
What AI actually changes
Strip a security champions program to its core and it was always a knowledge problem. Get security understanding as close to each developer as possible, then hope it survives the handoffs, from the security team to the champion to the team. Every handoff leaks. That is the layer AI actually changes.
The linchpin is threat modeling, and not the diagram. The diagram solves nothing on its own. What matters is the data underneath it, because once that data is available to an agent, you can finally deliver what shift-left promised and never did: the security context sits in the model’s context window, so every time an agent goes to work it already knows the application, the use cases, and how a fix should look. Findings get ranked by architecture instead of a raw severity score. False positives fall away because the model sees the whole system, not just the lines around the alert. Guidance arrives in the pull request as design direction, not a wall.
For years the only place to put security knowledge was a human head, which is exactly why it leaked at every handoff. The context window doesn’t. It carries the full picture into every agent on every change, and unlike a person it can be filled completely and refreshed the moment the system moves.
From there the work sorts into two jobs. Triage and planning is deciding what matters: signal pulled out of noise, risk reasoned about before a change ships, and only the real design questions routed to a human. Enforcement and execution is making it stick: decisions turned into enforced changes inside the workflow, so the guidance lives in the pull request and the Slack thread instead of the wiki nobody reads.
Where AI does not help
Every honest version of this story has a section like this one. AI does not replace security engineering. It changes the shape of the work, from clearing patches to deciding what the system should become. And it has real blind spots. It is weak at runtime defense, and weakest at the most human kind of flaw, the design mistake you only catch if you know why a feature exists and how it sits inside the larger product. Sometimes the model sees what a person would miss. Sometimes it is the other way around. That is the whole reason the discipline survives.
And no model fixes a program with no owner. Auto-remediation has existed for years as version-bump pull requests, and for most teams it becomes a backlog nobody merges, because someone still has to click merge and someone still has to care. Point AI at a broken program and you have not fixed anything. You have automated the slow burn.
What one team actually saw
One customer made the abstraction concrete. A US tech company, around 500 developers, a security team stretched closer to one-to-fifty than one-to-a-hundred, and roughly 25 security champions across the organization. The usual shape: a few deeply engaged, and a long tail who held the title and barely knew the security team, some who had never met them. Entire business units went dark. And the teams in the dark were often the ones shipping the riskiest things the company built.
Threat modeling was the use case, and before AI the hard part was the first step. The security team could coach the willing champions on STRIDE over time, but where nobody volunteered there was simply no coverage. AI changed where the work started. An initial framework did the heavy lifting and walked a champion through the first draft, so the job shifted from producing the model to reviewing it, sharpening it, and knowing when to raise a flag. Even for the disengaged, the system could surface a critical change early enough that a security engineer could reach out about something they would otherwise never have seen.
The part worth holding onto was the reaction from engineering. Builders describe security as friction almost by reflex. Here they described something they were glad to use. That is not what a feature earns. It is what happens when security ownership finally has ground to stand on.
What to do Monday
None of the moves here is bigger than it needs to be, and that is the point. Start with the honest question: what is your organization actually willing to fund. If the answer is catch the biggest risks first, weight threat modeling over vulnerability scanning, where the false-positive rate buries the signal anyway. Then start small. Do not build the perfect vulnerability dashboard before you have run one scoped process, because the only way to learn what each team needs is to run it. Hand the busywork to AI as you go, in the format each team already works in.
The spine holds the whole thing up. Fund the ownership first, then use AI to kill the busywork, never to run a broken program faster. Pick a real owner. Instrument one repo, not all of them. Let AI take the triage. The line that matters is not security versus developers. It is security, developers, and AI on the same side of the problem.
That is the problem Clover is built for: putting design-time security context in front of the people and the agents doing the work, so a security champion program finally has ownership to stand on and the busywork takes care of itself.
