kiterunner1 第三方插件安装前审计
何时用
- 用户要装、试装、或让你评估任何第三方 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观察项：常态行为，知道即可。
脚本是模式匹配：命中 ≠ 恶意，零命中 ≠ 无害。结论要落到读代码上。
脚本代替不了的人工必读
package.json的scripts（尤其postinstall/prepare）与dsh字段。cordis.patch.yml全文——特别是有没有!!js。- 入口文件里「读外部内容 → 拼进 prompt」的形状，那是提示词注入的主通道。
- 依赖来源：固定版本，还是
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 类