一个插件可能在两个完全不同的时点出问题，而多数扫描只覆盖其中一个。install script scanning 读的是插件声明"安装时要跑什么"：preinstall、install、postinstall 这几个钩子，以及这些钩子从网上拉下来的东西。postinstall script scanning 正因为如此才覆盖得最充分，而 runtime script risk 是另一半，也就是那段不是装的时候跑一次、而是每次调用插件都会执行的代码。搞清楚 install vs runtime scripts 在哪里分岔，才能判断一次干净的扫描结果到底值多少。下面讲的是 what plugin scanners check、这份覆盖在哪里止步，以及三个可以自己在本机上补上的检查。
install script scanning 覆盖了什么
扫描器读取清单文件和插件声明的安装钩子，再拿这些钩子去比对此前出过事的那些模式。主要看四样东西。
- 清单里声明的 preinstall、install 和 postinstall 脚本。它们是在安装期间以你的权限运行的，这也是 postinstall script scanning 最受关注的原因。
- 这些钩子发出的网络请求。安装时去拉一个第二阶段的可执行文件，正是多数告警所围绕的那个模式。
- 插件目录之外的文件写入。凡是碰到你的家目录、shell 配置文件或编辑器配置的，都会被标记。
- 打包声明。没有附带打包声明的插件更难审计，所以它的处理方式是扣分，而不是悄悄放行。
这些检查背后的机制写在 /blog/how-install-script-scanning-works，会触发告警的具体模式列在 /blog/dangerous-install-script-explained。
runtime script risk：一直在跑的那半边
上面那些都只发生一次。一个在安装时表现得很规矩的插件，完全可能在每次调用时做别的事；而那段代码就是普通的插件源码，扫描器本身没有理由单独把它当成危险项。
- 每次运行时从环境变量或配置文件里读凭据。
- 正常使用过程中的对外请求。不读代码的话，它和正常的遥测上报长得一模一样。
- 事后写进项目目录的文件，而不是安装时写的。
- 由输入拼出来的 shell 命令，风险取决于输入本身，而不是那段脚本。
这就是缺口所在。安装期的行为是声明式的、结构化的，容易检查；运行期的行为只是代码在干代码该干的事，要看懂它是人的活。
| 安装脚本 | 运行时脚本 | |
|---|---|---|
| 运行时机 | 安装时一次 | 每次调用 |
| 存放位置 | 清单钩子 | 插件源码 |
| 谁来检查 | 静态 install script scanning | 很少，且主要靠人工评审 |
| 权限 | 你的用户账号 | 你的用户账号加上你的凭据 |
| 典型失效方式 | 从网络拉第二阶段载荷 | 长期缓慢地泄露或篡改 |
| 是否体现在扫描结果里 | 是 | 通常不 |
install vs runtime scripts：边界到底在哪
边界不在文件上，而在代码运行的那个时点；同一个插件可以把同一个动作放在边界的任意一侧。
- 安装时下载一个辅助程序的插件，做的是安装期动作，也就在安装期被评判。
- 同一个插件每次运行时检查更新，做的是运行期动作，而这条路径很少被扫描。
- 往你的 shell 配置里写内容的钩子是安装期的；每次会话读取这份配置的插件是运行期的。
- 多数插件两边都有，这也正是一次干净的安装扫描能告诉你的比看上去要少的原因。
一次干净的安装扫描，说明的是安装过程是诚实的；它不说明这个插件跑起来之后依然诚实。
运行期那半边，自己怎么补
你不需要逐行审源码。三个检查能覆盖大部分要紧的地方，而且它们的成本可控，因为你只需要对那些已经通过安装扫描的插件跑一遍。
值得花一个下午的三个检查
- 读一遍网络调用。在插件源码里搜对外请求，看它们发到哪。正常的遥测会写明端点，说不清来源的就值得问一句。
- 看它从环境里读了什么。按名字去取 token 或密钥的插件，应该在 README 里说明。一份好文档长什么样，写在 /blog/how-to-evaluate-plugin-documentation-quality。
- 盯住第一周。新插件先装在你能察觉到异常写入的机器上，而不是一次铺开。CI 那一侧的做法在 /blog/ci-cd-plugin-scanning。
常见问题
- 一次干净的安装扫描意味着插件安全吗？它意味着安装过程是规矩的。运行期行为是另一回事，任何静态安装扫描都对它无从评价。
- 为什么 runtime script risk 更难打分？因为同一段代码无害还是有害取决于意图，而意图不写在清单里。人工评审抓得住，模式匹配抓不住。
- 带 postinstall 脚本的插件是不是都该避开？不是。不少正经插件要靠它编译原生代码或拉取平台二进制。要看这个钩子具体做了什么，而不是仅凭存在与否就否掉。
- 既然运行期不扫描，评分从哪来？评分覆盖维护状况、文档质量、生态健康度和安装期行为。评分独立于开发者自报数据这件事，写在 /blog/dsh-plugin-review-process。
把一次干净的安装扫描当成第一道闸门，而不是最后一道。dshquality.com 上每个插件都有评分页，写明哪些查过、哪些没查，你能直接看到自己面对的是整幅图的哪一半。评分背后的评审流程在 /blog/dsh-plugin-review-process，我们发布的全部文章在 /blog。