插件白名单是把「我们被入侵了」变成「我们根本没批准过」的最短路径。如果你的开发团队从共享注册表安装 DSH 插件，白名单就把插件选择从个人猜测变成团队决策。本指南讲解如何为开发团队配置插件白名单、背后的策略，以及如何在不拖慢人的前提下强制执行已批准清单。
插件白名单是什么
白名单是一组团队已审查并批准的插件。不在清单上的，安装即被拦截。黑名单是对已知坏插件做反应，白名单则默认一切不可信，直到它赢得一席之地。对供应链安全而言，这种默认拒绝的姿态正是你想要的。
为什么团队插件策略胜过临时救火
- 事故减少，因为高风险长尾根本装不进来
- 新人拿到的是安全默认，而不是空白搜索框
- 审计变成一行检查：插件在清单上吗？
- 审查压力分散到全队，而不是压在一个人身上
真正好用的分级
| 级别 | 规则 | 示例 |
|---|---|---|
| 已批准 | 已审查、评分 A/B，允许安装 | dsh-core、context-compressor |
| 有条件 | 仅开发环境允许，生产环境拦截 | 实验性研究插件 |
| 禁止 | 绝不安装 | 任何被标记的危险插件 |
三级比单一的是/否更好，因为真实工作有灰色地带。有条件级别让工程师能试验，又不向生产开放风险。
强制执行白名单
没人检查清单，它只是一份文档。把它接进流水线，让安装在封闭策略下失败。把白名单与 /blog/plugin-supply-chain-security 的安全扫描说明搭配，让每个已批准项背后都有评分支撑。
- 在 CI 加一道安装前关卡，拒绝清单外的插件
- 把清单放进版本控制，变更像代码一样被审查
- 订阅 DSH Weekly（/subscribe），让新的高分插件进入审查视野
拖垮白名单的错误
- 写一次就再不审查，评分会变、插件会老化
- 只凭 star 数批准，而不是看评分和警告
- 忘记拦截其他一切，悄悄重新打开门
常见问题
问：只有三个开发者也需要白名单吗？答：需要。三个人足够装三个不同的坏插件。白名单随风险扩展，不随人头数。
问：多久审查一次？答：每月一次是好节奏。把审查绑到你的 DSH Weekly 摘要，让新的安全插件进来、过期的出去。
关于 DSH Quality
DSH Quality 从维护、文档、npm 健康和安全四个维度为每款插件评分，让你的白名单建立在证据而非感觉上。来 dshquality.com 开始评估插件，阅读供应链指南，或订阅 DSH Weekly 获取新的安全推荐。