A shift-left program with no human layer is a tooling deployment in disguise. The CLI runs, the PR bot comments, the IDE flags risks — and when the inevitable edge case appears, the developer has nowhere to go except a Slack channel where the security team triages a backlog. That bottleneck is where good shift-left programs go to die.
The fix is a security champions program. Champions are engineers embedded in product teams who carry enough security context to handle the everyday questions, escalate the complex ones, and provide a back-channel between developers and the security team. They are not security experts. They are engineers who have signed up to be the first line of help.
This post is a design guide for security champions programs in 2026, focused specifically on the supply chain dimension of shift-left. It draws on patterns from organizations running Safeguard at scale and on the broader practice of DevSecOps champions programs.
What a champion actually does
The champion role is often defined too broadly. Job descriptions list "evangelize security," "support adoption of security tools," "advise on threat modeling," and a dozen other items that no engineer with a real day job can sustain. The list of responsibilities matters less than the actual hours.
A realistic champion role is two to four hours a week of dedicated time, with three concrete responsibilities. The first is first-line triage: when a developer on the champion's team hits a security finding they do not understand, the champion is the first person they ask. The champion either resolves the question directly or escalates to the security team with context that saves the security team time.
The second is policy feedback: champions surface friction patterns from their teams back to the security team. When a policy is firing too often, when a suggestion is wrong, when the override path is broken, the champion is the person who notices and reports. This feedback loop is what keeps the program from drifting.
The third is change advocacy: when the security team rolls out a new policy, a new gate, or a new tool, the champion is the local voice explaining why. Champions are not the implementer, but they are the translator between security intent and engineering reality.
Three responsibilities, four hours a week, no more. A champion program that asks for more will not retain its champions.
Selection: volunteers, not draftees
The single biggest predictor of champion program success is how the champions were selected. Programs that draft champions — assigning the role based on title or seniority — tend to produce reluctant champions who do the minimum and burn out within six months. Programs that recruit volunteers tend to produce engaged champions who improve the program from the inside.
The recruitment pitch matters. Frame the role around growth, not chores. A champion gets dedicated time to learn supply chain security, direct exposure to the security team's work, and visibility on a problem that matters to the company. That is a development opportunity, not a tax. Engineers who care about security as a craft will self-select.
The other selection signal worth respecting is the engineer's tenure on the team. Champions need credibility with their teammates, and that credibility comes from being an effective engineer who understands the team's codebase. A new hire, however motivated, will struggle to influence their peers. Look for engineers who have been on the team at least six months and who already get pulled into design discussions.
A practical model: post the champion role to the engineering org, accept applications from anyone who has been on their team six months or more, and select with input from the candidate's manager. Aim for one champion per 10 to 15 engineers. Smaller ratios mean champions are stretched. Larger ratios mean the program does not have enough coverage.
Training: less than you think
Champions do not need to become security experts. They need to know enough to handle the 80 percent of supply chain questions that come up in their teams, and they need to know how to escalate the other 20 percent without losing context.
A two-day onboarding course, repeated quarterly for new champions, covers the practical material. Day one is supply chain fundamentals — how dependency resolution works, what an SBOM is for, how a typosquatting attack actually plays out, what license risk means for the company. Day two is hands-on with the tooling — how to read a Safeguard PR comment, how to grant a waiver, how to file a finding back to the security team, how to use the CLI to investigate a suspicious dependency.
Beyond the onboarding, training is continuous and asynchronous. The security team posts a monthly digest of recent supply chain incidents, with short writeups of what happened, what would have caught it, and what the team is doing about it. Champions are the primary audience for these digests. The digests serve as ongoing training and as raw material for champions to discuss with their teams.
The thing not to do is to require champions to attend every security team meeting, sit through every incident review, or read every advisory. That path leads to burnout. Respect the four-hour-a-week budget and design training to fit inside it.
Tooling: champions need their own surface
Champions need a different view of the security tooling than either developers or the security team. They need enough visibility to triage their team's findings without being overwhelmed by the company's findings. They need enough authority to grant waivers and resolve issues without paging the security team for routine work. And they need enough context on what is happening across teams to identify patterns.
In Safeguard, champions get a dashboard scoped to their teams' repositories. The dashboard shows open findings, recent waivers, policy gates currently failing, and a feed of incidents from the broader supply chain feed that affect their team's dependency graph. Champions can grant short-duration waivers, mark findings as accepted-with-context, and route specific findings to the security team with a single click.
The scoping is important. A champion looking at a dashboard with 5,000 findings across the company will give up before they help anyone. A champion looking at 30 findings across their team's three repositories will work through them in an hour.
Retention: the hard part
Champion programs lose champions for predictable reasons, and good programs design against each one.
Burnout is the most common cause. The fix is to enforce the four-hour-a-week budget. If a champion is consistently spending more time, that is a signal the program is asking too much, not that the champion needs to be more efficient. The security team should treat champion overrun as their problem to solve.
Lack of recognition is the second. The fix is to make champion contributions visible. The security team should publish a quarterly summary of champion activity — findings triaged, waivers granted, policy feedback contributed — and share it with champions' managers. Performance review season is when this matters. A champion whose security contributions disappear into the manager's blind spot will not renew the role.
Drift is the third. A champion who has been in the role for two years, hasn't trained any new champions, and hasn't surfaced any policy feedback is probably not engaged. The fix is to set a default rotation — eighteen months on, six months off — with the option to renew if both sides want to. Rotation keeps the program fresh and creates a pool of former champions who carry security context back to their teams.
Measuring program health
Three metrics track whether a champion program is working.
Time-to-first-response for security questions in champion-supported teams versus teams without champions. If the program is working, questions get answered faster in supported teams.
Escalation quality. What percentage of escalations arrive with enough context that the security team can act immediately? A high number means champions are doing the triage work well.
Champion retention. Aim for at least 70 percent completing their full term and at least 30 percent renewing. Lower numbers indicate the program is asking too much or recognizing too little.
The compounding effect
A well-run champion program compounds over years. Former champions return to their teams as security-aware engineers. Current champions train their successors. The security team gains a network of trusted contacts across engineering, which makes every initiative easier to roll out.
The program is not free. It costs engineering time, training investment, and management attention. But it is the cheapest way we know to make a shift-left program survive contact with a real engineering organization. Tooling alone gets you part of the way. The human layer carries you the rest.