A plugin quality gate is a check that runs at install time, before a third-party package reaches your runtime. An install quality gate costs minutes; removing a bad dependency from production costs days.
Install time is the cheapest place to stop a bad dependency
A bad plugin in production makes you pay twice. You diagnose across code you did not write, then remove it by rewriting every call site and retesting under pressure. One dependency can take a team three days to evict. Ten minutes of review at install is a 200x cheaper fix. The gate exists because install is the only moment where saying no is free. The review is not deep; it is a glance at signals you already have.
What a quality gate should actually check
- Maintenance recency: when was the last commit, and is the gap widening?
- Maintainer reachability: is there a working security contact, or a void?
- Requested permissions and network access: does it ask for more than its function needs?
- Build step: does it bundle a compiler or a postinstall script that runs on your machine?
- Tests: does the repo ship a test suite, and does CI actually run it?
- Licence: is it compatible with how you distribute your product?
- Download provenance: was the artifact signed, and does it match the source?
- Version pinning: is the version you pin the exact version that was scored?
Most of these are seconds of metadata work. The trap is the last item: a plugin can score well at 1.4.0 and change hands at 1.4.1 without renaming. Bind the score to the pinned version, not the package name. Automate it and the cost drops to near zero.
| Gate type | What it checks | False-positive cost | Team friction | Who it fits |
|---|---|---|---|---|
| No gate | Nothing | Zero at install, high in prod | None | Hobby projects, throwaway code |
| Advisory gate | Flags score below threshold | Low; can be ignored | Minor | Most teams, first adoption |
| Blocking gate | Fails install on security issues | High if misconfigured | Moderate | Regulated or large orgs |
The false-positive problem
A gate that blocks every low score gets disabled by the next engineer hit with a false alarm at midnight. Grade by risk. Stay advisory for low-risk plugins: show the score, log the decision, let it through. Block only on security signals, an unknown maintainer plus network access, an unsigned artifact, a missing licence. Earn trust instead of fighting it, and promote rules to blocking as your data grows. False positives are cheap to absorb when the gate is advisory.
First install versus every version bump
Gating only the first install, then auto-approving updates, is a mistake. Updates are where risk returns: a plugin is sold, the new owner ships a version that phones home, and your pipeline accepts it because the name is allowlisted. Run the gate on every version bump. Cache the score per version and re-check when the pin changes. Nothing installs without a current score for the exact version. A renamed fork is still a new risk surface.
Write the policy so it survives staff turnover
Policies rot when they keep only the verdict. Blocked: plugin X tells the next engineer nothing once X has a new owner. Write the reason: the scored commit hash, the failing signal, and what would change your mind. A rule like fail when maintainer is unreachable AND network access is requested is reviewable and transferable. A banned-name list is a liability the day its author leaves. Six months later, only the written reason explains the call.
Why we trust the author is not a policy
Trust is a feeling, not a control. A careful author can be compromised this week, sell the package, or lose interest. The gate asks you to verify state at a point in time and repeat it. Never use the vendor's own score as your gate; they are incentivised to look good. That is why the score must be independent of the plugin vendor. Read why on /blog/why-independent-plugin-scoring, and see the score itself at /. Independence is the whole point of the score.
A transparent weighted score makes the gate defensible
A gate nobody can interrogate becomes an argument. A transparent weighted score, maintenance, security, documentation, community, performance, each visible, turns a no into a readable sentence. When challenged, point at the failed dimension and its weight. That is the gap between arbitrary and defensible. The score on / shows exactly why a plugin landed where it did, which is how a gate survives a skeptical team. Anyone on the team can reproduce the decision.
Start here
Adopt an advisory gate first. Log every install and every override with its reason. After two weeks, review what got waved through and why. Only then promote the rules that proved reliable from advisory to blocking. You get a working gate in days, not a committee in months, and it stays honest because the evidence is already on record. This keeps the gate honest from day one.
FAQ
Does a quality gate slow down development? Only at install, and only by minutes. The cost it prevents is days of production cleanup. Teams that log overrides usually find that 90 percent of installs pass the gate untouched. The gate is a filter, not a wall.
What if the plugin I need fails the gate? Do not bypass it silently. Record the specific signal, note your compensating control, and let the advisory gate log the override. A blocked plugin with a documented reason is acceptable; a silent bypass is not.
Can a small team afford this? Yes. Most checks are metadata lookups that run inside your existing install command. You need a script, a threshold, and a log file, not a platform. The / score gives you the weighted input for free.