Most teams end up in one of two places: plugins are banned outright, or anyone can add one and nobody looks. A plugin review process is the third option, and it is faster than both. This guide covers the plugin review checklist a new plugin passes before it lands, where to put the PR plugin gate so it does not become a bottleneck, and a dsh plugin approval workflow that keeps reviewing new plugins before install a ten-minute job instead of a scheduled meeting.
Why a ban fails and open install is worse
A ban does not stop plugin use. It moves it to personal machines and throwaway branches, where nothing is recorded and nobody reviews anything. Open install is the opposite failure: the dependency list grows, the review surface grows with it, and the first time something breaks you have to audit a hundred entries under time pressure.
- Ban: no record, no review, no way to answer "what are we running" in an incident.
- Open install: full record, zero review, and a dependency list nobody can vouch for.
- Review process: the record exists and the review is scaled to the risk.
The plugin review checklist
Keep it to eight items, in this order. The first four are mechanical and take about four minutes; the last four are judgement calls.
- Identity: does the index name match the source repo name, or is there a wrapper in between?
- Recency: when was the last publish, not the last commit?
- Install path: read the install script. Anything fetched at runtime is a separate review.
- Score: check the current DSH score and, more usefully, whether it has been dropping.
- Scope: does it ask for permissions or file access wider than the job it does?
- Maintenance: open issue response time over the last three months.
- Bus factor: how many people have committed in the last six months?
- Exit plan: if you remove it next quarter, what breaks?
The first four are the ones that catch supply chain problems. The last four decide whether you want to depend on it for a year.
Where the PR plugin gate belongs
A PR plugin gate is a check in CI that runs when a pull request touches the plugin manifest. It does not reject; it prints what changed and what the reviewer should look at. There are three sensible placements.
| Placement | What it catches | Cost |
|---|---|---|
| Pre-commit hook | Typo and name errors before a PR exists | Low, runs locally |
| PR check (recommended) | Every manifest diff, with score and install-script summary | Low, a few seconds |
| Release gate | Plugins added outside the manifest on developer machines | High, needs machine inventory |
Start with the PR check. It covers the path almost every plugin actually takes, and the diff it prints is the same artifact a human reviewer would assemble by hand.
Thresholds worth enforcing
Pick numbers before you need them, and make them few. Three tiers is enough.
| Tier | Condition | Action |
|---|---|---|
| Auto-approve | Score 80+, install script bundled, index name matches repo | Merge without review |
| One reviewer | Score 60-79, or any single mechanical check unclear | One approval, checklist attached to the PR |
| Hold | Score under 60, runtime fetch in install script, or name mismatch | Needs a written reason and a second approval |
A gate that blocks everything gets disabled within a month. A gate that prints a diff and asks one question survives, because it is cheaper than the argument it replaces.
Rolling it out without annoying everyone
- Run the gate in report-only mode for two weeks. Collect what it would have flagged before you enforce anything.
- Approve the existing manifest in one commit, so the baseline is clean and every later diff is meaningful.
- Put the checklist in the PR template, not in a wiki nobody opens.
- Name one owner per plugin in the manifest. Rotating ownership is the usual reason review decays.
- Re-review quarterly, and only the entries whose score moved.
FAQ
- How long should a review take? Ten minutes for a tier-two plugin, and most of that is reading the install script.
- Does this slow down installs? No. The gate runs on the manifest diff, not on the developer machine.
- What about plugins installed globally outside the repo? That is the release gate tier, and it needs machine inventory first.
- Do we need to review removals too? Only when the plugin was a tier-three approval, since that is where the exit plan was written down.
Start with the checklist and the PR check; the rest can come later. The team-wide version of this is covered in /blog/plugin-supply-chain-security-team-enforcement, the per-plugin red flags are listed in /blog/how-to-avoid-risky-dsh-plugins, and if you want to fix the list you already have, /blog/setting-up-a-plugin-allowlist-for-your-dev-team walks through it. Score thresholds are explained in /blog/dsh-quality-score-decoded, and the full plugin index is at /.