被隔离的插件，是扫描器已经标记、但你还没下判断的那些。团队在这个阶段最耗时，因为人的第一反应是去读源码，而此时风险还在后台活着。下面这套 flagged plugin workflow 按真正管用的顺序走：先冻结版本，切断它能碰到的东西，然后才读脚本。里面包含可以在笔记本或共享构建机上跑的 plugin isolation steps，也回答了整件事的核心问题：how to quarantine a dsh plugin，而不用靠猜这个包到底能碰到什么。一次 plugin quarantine 是暂置状态，它的终点是一个决定，不是一种感觉。
「被标记」到底是什么意思
当插件的安装脚本命中了此前在风险插件里见过的模式，扫描器就会给它打标记。这只是模式匹配，不是判定。有的插件被标记只是因为 postinstall 钩子会去拉一个二进制文件，而一些正常工具就是这么做的；反过来，也有插件过了扫描，却在运行时干着不太对劲的事。
| 检查项 | 能抓到什么 | 抓不到什么 |
|---|---|---|
| 危险安装脚本 | postinstall 钩子、curl 直接管道给 shell | 安装之后才跑的东西 |
| 缺少 dsh.bundle | 跳过打包元数据的插件 | 字段写了但内容不对的插件 |
| 维护停滞 | 不再发版的仓库 | 活跃仓库里的某一个坏版本 |
把告警当成一次「去看一下」的请求，而不是结论。标记背后的机制在 /blog/how-install-script-scanning-works。
第一步：冻结版本
在做别的事之前，先把精确版本锁死。自动更新正是「从安全版本开始的评审，结束时却停在另一个版本」的原因。
- 把你要评审的那个版本号记下来。
- 在 lockfile 里锁住它，这样重装也不会漂。
- 如果插件已经装上了，从 lockfile 重装，别去拉最新版。
第二步：切断它能碰到的范围
隔离排在读代码之前，因为读要花一个下午，隔离只要一分钟。下面的 plugin isolation steps 只遵循一条规则：在你搞清它做什么之前，先限制它能碰到什么。
- 放进容器或一次性的虚拟机里跑，环境里不放任何凭据。
- 指向一个临时目录，而不是你正在做的项目。
- 如果插件没有理由发网络请求，就把出站网络断掉。
- 用一把权限最小的独立 key，别用你主账号那把。
隔离很便宜，而且可以撤销。撤销一次事故，两样都不是。
第三步：读安装脚本
把脚本打开读，别只看描述。扫描告诉你该往哪儿看，剩下的就是老实读。
- 找出任何往插件目录之外写东西的操作。
- 检查每一个网络请求：发到哪儿去，有没有把文件内容带出去。
- 留意混淆、base64 大段字符串，或者用字符串片段拼出来的命令。
- 确认 postinstall 钩子和 README 里声明的插件功能对得上。
读完没发现异常，说明这次标记是误报，写一行说明就可以放行。扫描器找的具体模式列在 /blog/how-install-script-scanning-works。
第四步：做决定，并且写下来
隔离以决定收尾，而决定需要留档。插件问题往往几个月后才冒出来，而查的人当时并不在场。
| 结论 | 要记什么 | 下一步 |
|---|---|---|
| 放行 | 评审的版本、读过脚本、谁批的 | 解除版本锁定，保留在观察列表 |
| 保持隔离 | 它能碰到什么、为什么可以接受 | 保留沙箱，下个版本再评审 |
| 移除 | 触发移除的原因 | 卸载、清理配置、记录替代方案 |
三种结论，各写一行。短到这个程度，人才真的会填。
常见问题
- 被标记就等于坏插件吗？不等于。标记的含义是安装脚本命中了一个值得查的模式。很多被标记的插件读完是没问题的。
- 插件要隔离多久？到有人读完安装脚本并写下结论为止。一天很正常；拖到三周，说明根本没人负责。
- 一定要用容器吗？不一定。临时目录加一把一次性 key 就能覆盖多数评审场景；但如果脚本要联网，容器是更稳的默认选择。
- 插件已经上了生产怎么办？先冻结版本让状态不再变化，然后按同样的步骤走一遍。移除要等到有了替代方案再说。
dshquality.com 上每个插件页都会列出扫描结果和构成等级的各项信号，你能看清是哪一项检查提出了标记，而不用猜。扫描机制在 /blog/how-install-script-scanning-works，C 级和 B 级的判断分别见 /blog/c-grade-dsh-plugins-good-enough-trap 和 /blog/what-a-b-grade-dsh-plugin-tells-you，站内全部文章在 /blog。