A plugin allowlist is the shortest path from 'we got compromised' to 'we never allowed that.' If your dev team installs DSH plugins from a shared registry, an allowlist turns plugin choice from a personal guess into a team decision. This guide walks through setting up a plugin allowlist for your dev team, the policy behind it, and how to enforce approved plugin lists without slowing people down.
What a plugin allowlist is
An allowlist is a named set of plugins your team has reviewed and approved. Anything not on the list is blocked at install. Unlike a blocklist, which reacts to known-bad plugins, an allowlist assumes everything is untrusted until it earns a spot. For supply-chain safety, that default-deny posture is what you want.
Why a team plugin policy beats heroics
- Incidents drop because the risky long tail never gets installed
- New hires get a safe default instead of a blank search box
- Audits become a one-line check: is the plugin on the list?
- Review load spreads across the team instead of landing on one person
Tiers that actually work
| Tier | Rule | Example |
|---|---|---|
| Approved | Reviewed, scored A/B, install allowed | dsh-core, context-compressor |
| Conditional | Allowed in dev only, blocked in prod | experimental research plugins |
| Denied | Never install | anything flagged dangerous |
Three tiers beat a single yes/no because real work has gray areas. A conditional tier lets engineers experiment without opening production to risk.
Enforcing the allowlist
A list nobody checks is just a document. Wire it into your pipeline so installs fail closed. Pair the allowlist with the security scanner write-up at /blog/plugin-supply-chain-security so every approved entry has a score behind it.
- Add a pre-install gate in CI that rejects plugins outside the allowlist
- Keep the list in version control so changes are reviewed like code
- Subscribe to DSH Weekly (/subscribe) so new high-score plugins surface for review
Mistakes that sink allowlists
- Writing it once and never reviewing, scores move and plugins age
- Approving by star count alone instead of score and warnings
- Forgetting to block everything else, which quietly reopens the door
FAQ
Q: Do we need an allowlist if we only have three developers? A: Yes. Three people is enough to install three different bad plugins. The list scales with risk, not headcount.
Q: How often should we review it? A: Monthly is a good rhythm. Tie reviews to your DSH Weekly digest so new safe plugins get in and stale ones get out.
About DSH Quality
DSH Quality scores every plugin on maintenance, docs, npm health, and security so your allowlist is built on evidence, not vibes. Start evaluating plugins at dshquality.com, read the supply-chain guide, or subscribe to DSH Weekly for new safe picks.