所谓 dsh 安全公告，是当索引里的某个插件从「值得关注」跨到「现在就得处理」时，我们发布的通知。本期每周公告汇总了过去七天里提出的所有插件安全公告，说明每一档严重级别的含义，并演示如何把公告订阅源接进团队已经在看的工具。如果本周你只查一件事，就查一查你装过的插件有没有出现在下面的清单里。
什么情况会触发公告
公告是绑定到具体版本的具体发现，不是对质量的整体印象。一个插件可以带着平庸的评分过好几个月，也不产生一条公告。以下四种情况会触发：
- 危险安装脚本，即安装步骤做了普通插件没有理由做的事：访问网络、往自身目录之外写文件，或读取凭据文件。
- dsh.bundle 声明缺失或自相矛盾，插件声明的能力与打包进去的文件对不上。
- 破坏信任链的维护者或仓库变更，比如把仓库转给了同一周才注册的账号。
- 依赖本身被标记，因为风险是顺着依赖树进来的，不只来自顶层包。
严重级别如何分档
| 级别 | 触发条件 | 应对动作 |
|---|---|---|
| 严重 | 已发布版本中存在危险安装脚本，或已确认的恶意载荷 | 移除插件，轮换它可能接触到的凭据，再排查装过它的机器 |
| 高 | 缺少 bundle 声明，同时安装步骤含混淆代码或联网行为 | 先禁用插件，留一份日志副本，等上游修复后再启用 |
| 中 | 维护者账号变更、仓库转移，或某个依赖已超过一年无人维护 | 锁定版本，并把该插件加入观察名单 |
| 低 | 文档漂移、元数据过期，或评分下滑但没有任何安全信号 | 记下来，放到下一轮评审里处理 |
级别描述的是紧急程度，不是恶意程度。一条「低」级公告打在你并不依赖的插件上，只是噪音；同样级别打在一个能碰到 CI 凭据的插件上，就值得你花一小时。
读公告时不要过度反应
- 先核对版本。针对 2.1.0 的公告，在你锁定 1.8.4 的情况下并不适用，插件页会写明受影响的版本范围。
- 把安装期风险和运行时风险分开。多数发现落在安装步骤，也就是说去年就装好的插件，可能根本没执行过那段被标记的代码。
- 留意哪些没被检查。每条公告都会列出扫描范围，一句诚实的范围说明，比一个自信的结论更有用。
- 先决定，再删除。移除插件会毁掉写报告需要的证据，所以先禁用、先做快照。
版本号从哪来
公告来自我们可以核实的元数据：已发布版本、按纯文本读取的安装脚本、声明文件，以及仓库事件。公告里没有任何一项依赖维护者自述插件做了什么，这也是公告和宣传页可能说法不一的原因。
公告是对某一版本在某一时点的陈述。把它当作核查的开始，而不是核查的结论。
把汇总变成真正的动作
- 订阅这个源，让公告汇总出现在团队已经在用的地方，而不是指望有人记得去看。
- 每周拿清单和已安装列表对一遍。对着已知清单花五分钟，胜过一场没人排期的审计。
- 把跟进责任派给当初批准该插件的人。批准和回滚应该归同一个负责人，否则两件事都会被一直往后推。
- 把决定记下来，包括「决定什么都不做」。半年后，一个没有记录的决定看起来就是失职。
常见问题
- 公告和评分有什么不同？评分描述一段时间内健康状况与卫生程度，公告描述带时间戳的单条发现。
- 「严重」公告是不是说明我的机器已经被攻陷了？不是。它的含义是这个版本含有可能在安装它的机器上造成危害的行为。你的机器有没有中招，取决于你装过什么、什么时候装的。
- 插件能撤销公告吗？可以。维护者发布修复版本，且该版本的扫描结果干净时，公告会保留在页面上作为历史记录。
- 是不是该立刻移除所有被标记的插件？不该。先禁用、先做快照，再决定。直接移除会毁掉证据，万一问题属实你就没法查了。
- 为什么有些公告写得含糊？因为扫描只报告它能核实的部分。一条范围说明诚实的含糊公告，胜过一条靠猜测撑起来的自信公告。
dshquality.com 上每个插件页都列出了针对它的公告，包括检查了什么、没检查什么。每周公告可在 /subscribe 订阅，实时插件索引在 /，扫描器如何下结论见 /blog/how-install-script-scanning-works，其余文章在 /blog。