第三方插件安装前审计

何时用

• 用户要装、试装、或让你评估任何第三方 DSH 插件之前。
• 用户问「这个插件安全吗」「它会不会偷数据」「它联网吗」。
• 自己写完插件准备发布前，自查一遍。

为什么不能只靠读代码

DSH 官方 Discussion #454 与第三方插件安全审计报告的共同结论：DSH 对「模型行为」是生产级防护，对「插件代码」零安全设计。

• 插件与宿主同进程、同权限。
• 文件沙箱只挡「写」，不挡「读」。
• patch 层 !!js 表达式在加载期执行，静态读代码时容易漏。
• 恶意 bundle 安装即执行；事后 remove 清不掉已落下的后门。

所以「装之前先看一眼它要碰什么」是唯一低成本的闸门。

怎么跑

脚本在 scripts/audit-plugin.ps1——用本 skill 的 base directory（宿主会在加载时给出绝对路径）拼出完整路径再调用。

# 审计一个目录
pwsh -File "<base>/scripts/audit-plugin.ps1" -Path <插件目录>

# 按包名审计：自动在 <DSH_HOME>/profiles/*/node_modules 与 npm 全局里找
pwsh -File "<base>/scripts/audit-plugin.ps1" -Path <package-name>

# 多个目标一次传：逗号分隔成数组。重复写 -Path 会报参数绑定错误
pwsh -File "<base>/scripts/audit-plugin.ps1" -Path ./plugin-a,./plugin-b

# 机器可读，便于自己二次统计
pwsh -File "<base>/scripts/audit-plugin.ps1" -Path <目录> -Json

需要 PowerShell 7+（pwsh），Windows / macOS / Linux 均可。脚本只读：不改文件、不装东西。

怎么读结果

三层，别混在一起看：

• VETO 硬否决项：单项即可否。逐条确认是「真实行为」还是「误报」——脚本已跳过纯注释行，但仍可能命中字符串常量或文档文本。
• RISK 能力清单：不是指控，是「它有权做什么」。重点看出网域名清单，分清已标注的文档/命名空间类域名与真实连接目标。
• INFO 观察项：常态行为，知道即可。

脚本是模式匹配：命中 ≠ 恶意，零命中 ≠ 无害。结论要落到读代码上。

脚本代替不了的人工必读

1. package.json 的 scripts（尤其 postinstall / prepare）与 dsh 字段。
2. cordis.patch.yml 全文——特别是有没有 !!js。
3. 入口文件里「读外部内容 → 拼进 prompt」的形状，那是提示词注入的主通道。
4. 依赖来源：固定版本，还是 git+ / github: / 运行时拉远端代码。

审完之后：隔离试装

别直接装进正在用的 profile。用临时 profile + 独立端口：

dsh plugin --profile tmp-audit add <包名或 github:owner/repo#<commit>>
dsh --profile tmp-audit --dump-config     # 核对组合能否正常解析

• 装插件时必须停掉正在运行的 DSH，否则 profiles/<name>/node_modules 会被删到一半失败，留下「当前能跑、重启必死」的 profile。
• 尽量 pin 到 commit（github:owner/repo#<sha>），不要让依赖跟着默认分支漂。

输出长这样

真实跑一例（审一个已发布的诊断类插件）：

  结论：未命中硬否决项 —— 请核对下方能力/域名清单后决定
  硬否决项 0 条 · 需确认能力 6 类 · 观察项 0 类