Most teams treat a plugin decision as a personal one, which is why plugin safety culture never forms. A security champion program fixes that by handing one person per team named ownership instead of a policy nobody opens twice. Below is what security champion responsibilities look like on a team too small to have a security team, how to start the program without adding headcount, and where a champion should stop.
Why a policy document is not a culture
Every team that has tried this has written the document first. It rarely changes anything, for three reasons that have nothing to do with the writing.
- The document has no owner once the meeting ends. Nobody is assigned to notice that a plugin was added last Tuesday, so nobody does.
- Review happens after install, not before. By the time anyone looks, the plugin has already run its install script and the argument is about removing something people now use.
- The score exists but nobody is assigned to read it. A grade sitting in an index is information; a grade someone checks every Monday is a control.
A champion closes that gap by being a name rather than a rule. The rule already exists in most teams. What is missing is the person.
Security champion responsibilities, concretely
Five things, and none of them require a security background.
- Own the plugin list. One file, in the repo, listing what is installed and who asked for it.
- Be the first reviewer on anything new. Not the approver by force, but the person a teammate messages before installing.
- Run the weekly score pass. Ten minutes against the index, looking for entries whose grade moved rather than entries that are simply low.
- Keep the allowlist honest. Remove entries nobody has used in a quarter, because a stale allowlist is how a denied plugin comes back.
- Write the note when something is pulled. One paragraph on what was removed and why, so the next person does not reinstall it.
What a champion does each week
| Task | Time | Output |
|---|---|---|
| Review new plugin requests | 15 min | Approve, deny, or ask for a score first |
| Scan the installed list | 10 min | Any grade change flagged, direction noted |
| Check the allowlist | 5 min | Unused entries removed |
| Write one note | 10 min | What changed and why, in the repo |
Forty minutes a week. Teams that let this grow past an hour usually lose the champion by the second quarter, because the role quietly becomes a second job.
Starting a champion program with no headcount
You are not hiring anyone. You are naming someone who already reviews pull requests.
- One per team, not one for the company. A central champion cannot know which plugin a team actually depends on.
- Give them the score, not a rulebook. A number they can check is faster to act on than a document they have to interpret.
- Cap the time. Say out loud that this is forty minutes a week, and mean it.
- Rotate every two quarters. Rotation keeps the knowledge spread and stops the role from hardening into a bottleneck.
Where the champion stops
Three limits matter, mostly because crossing them turns a useful role into a blamed one.
- They do not approve high-risk installs alone. Two names on anything that touches credentials or network access.
- They do not write policy. They report what they see; someone else decides the rule.
- They are not the incident owner. If a plugin turns out to be hostile, that is an incident with its own process, not a champion failure.
A champion is the person who notices. The program breaks the moment they become the person who decides everything alone.
Getting the first champion through the first month
The first month decides whether the role survives. Three things make it stick.
- Start with the list, not with a rule. Writing down what is already installed takes an afternoon and produces something concrete.
- Pair the champion with the score. Reading grades is the part that feels like progress, and it is also the part that catches problems early.
- Report once, publicly. One short message a month on what changed is enough to make the role visible without making it a performance.
The full index lives on dshquality.com, and the four-pillar score behind every entry is explained at /blog/dsh-quality-score-decoded. Pair this with the allowlist guide at /blog/setting-up-a-plugin-allowlist-for-your-dev-team, the pipeline wiring at /blog/ci-cd-plugin-scanning, and the supply-chain write-up at /blog/plugin-supply-chain-security-team-enforcement. All posts are at /blog.
FAQ
- How many champions do we need? One per team of five to ten engineers. Below that the team lead can hold it; above that the list gets too long for one person to know.
- Does the champion need security training? No. The role is noticing and record-keeping, not analysis. Anything that needs real analysis should be escalated instead of decided locally.
- What happens when the champion leaves? Rotate every two quarters and keep the list in the repo, not in a document. Rotation is what stops the departure from becoming an outage.
- How is this different from an allowlist? An allowlist is a control that blocks installs. A champion is the person who keeps that control current, which is the part allowlists usually fail at.