[Show and tell] dsh-plugin-vetting：给第三方插件做"恶意行为体检"（静态扫描 + 运行时绊线）

[truelove-dreamer]

环境：DeepSeek Harness 0.1.0-rc.6，npm 包 dsh-plugin-vetting（零依赖，纯静态扫描，从不执行插件代码）｜ GitHub：truelove-dreamer/dsh-plugin-vetting

这是什么

DSH 的插件生态刚起步，任何人发布一个 dsh-plugin-* npm 包就能被装进 harness——而插件是在 harness 进程内执行的全权限代码（能读凭据、发网络、起子进程）。dsh-plugin-vetting 就是给这个场景做的启发式体检器：扫描已安装的第三方插件源码，按可疑模式打分并报告，像杀毒软件一样"提示风险"，而不是"拦截"。

威胁模型（先讲清楚边界）

• 它是绊线（tripwire），不是安全边界——恶意代码伪装成正常写法仍可能漏过；
• 扫描是静态的：只读源码匹配规则，从不执行插件代码；
• 官方包 @deepseek-ai/* 自动豁免（它们本身含 fetch/spawn 等正常行为）；
• 根治方案应由 harness 提供"挂载前扫描钩子"，本插件是该思路的独立原型。

功能

能力	说明
plugin_vet 工具 / /plugin-vet 命令	扫 $DSH_HOME/profiles/*/node_modules 下所有第三方 dsh-plugin-* 包
风险分级	权重累加 → SAFE / LOW / MEDIUM / HIGH，每条命中带文件:行号
运行时绊线（可选）	config.monitor: true 时包装 subprocess.spawn，可疑命令（外传网络、读 /proc/<pid>/environ）记警告日志，只记不改
白名单	config.allowlist 放行可信插件（见下）

真实运行示例

扫描我自己的 4 个已装插件：

[SAFE] dsh-plugin-pwsh-utf8@0.1.0
[SAFE] dsh-plugin-search-gate@0.1.0
[HIGH] dsh-plugin-credential-guard@0.1.0  score=10  ← 规则里声明了密钥文件名
[HIGH] dsh-plugin-security-audit@0.1.0    score=16  ← 引用了讨论帖 URL/凭据路径

第二行正好演示已知误报类：安全插件自己的规则引用敏感模式，启发式必然高分——这是特征不是 bug，用 allowlist 处理（如 allowlist: [dsh-plugin-credential-guard, dsh-plugin-security-audit]）。

安装

dsh plugin --profile web add dsh-plugin-vetting

profile cordis.patch.yml：

- id: plugin-vet
  name: dsh-plugin-vetting
  config:
    monitor: false   # 可选：运行时子进程绊线
    # allowlist: [ ... ]  # 可信插件

为什么不直接修 harness 本身

官方目前不收外部 PR（CONTRIBUTING），所以走的是官方推荐的外部插件路径。如果团队觉得"挂载前扫描"值得进核心，这个插件就是现成的原型——欢迎在评论里讨论把静态扫描做成 loader 挂载前的强制步骤。

相关

• 插件开发避坑（schema 校验）：discussions/1040
• 之前的安全加固插件集：dsh-plugin-search-gate / dsh-plugin-credential-guard / dsh-plugin-pwsh-utf8 / dsh-plugin-security-audit

[truelove-dreamer]

你好， 非常感谢你指出来，尤其开头那句"不是恶意，是误伤"——这个视角帮我补上了最实际的盲区。 先正面回答你问的那句："体检器自己会不会被绕过？" 会。它是个绊线，不是门禁。 你点出的两个 fail-closed 方向，我们都照做了： ① 运行时动态加载（你说：静态扫描看不到网络内容） 已在 README 明确声明："运行时动态加载的代码（下载后 eval、require 远端模块）不在静态扫描范围"——原话就是你建议的措辞，防止用户误以为扫过就安全。"从不执行插件代码"这个边界保留，但不再给人"扫过 = 安全"的错觉。 ② eval 降级信任（你说：即使总分 SAFE 也要标"需人工确认"） 已实现：任何命中 eval / new Function / vm.runInNewContext 的插件，无论总分多少都强制标 [REVIEW: dynamic code execution present]（独立 needsReview 字段）。正如你说的——eval 是静态扫描最大的盲区，它的存在本身就该降级信任，而不是等凑够分数才 HIGH。 你提的另外三点也已实现（v0.2.0，12 个单测全绿）： 误伤 → "建议收窄权限"而非"可疑"：新增 sloppy 规则（fs.readFileSync(process.env.HOME + '/.ssh/config') 这类宽松路径、字符串拼接、递归遍历 home），命中只进 suggest-narrowing 建议区，不扣分、不标可疑； 传递依赖：统计声明依赖数 + 就地扫描嵌套 node_modules/* 的生命周期脚本，并如实报告"该插件有 N 个传递依赖未检查"（提升到宿主 node_modules 的依赖确实扫不到，不假装覆盖）； prepare/prepublishOnly：install 规则已扩展匹配 install|preinstall|postinstall|prepare|prepublishOnly，且 package.json 文本现在也参与规则匹配（之前只扫 .js/.ts，会漏脚本字段）——你指出的"git 依赖安装时 prepare 也会执行"很关键。 另外两点我的补充声明（不是你的原话，但顺着你的思路想到的，一并说清楚，免得你以为漏了）：本工具按包名豁免 @deepseek-ai/*，恶意载荷若藏进官方依赖会被跳过——这是豁免机制的已知盲区；以及伪装成正常写法的恶意代码仍可能绕过正则——所以输出措辞是"未发现可疑模式"而非"安全"。 你最后那句"趁早做进 v1，后面补的成本更低"——完全同意，这四点已经是 v1 的一部分了。

[Electricitysheep]

静态扫描 + 运行时绊线（从不执行插件代码）——和 dsh-plugin-doctor（装前兼容检查）、check-dsh-profile.mjs（boot 前检查）一起，把"装前/装后/运行时"三段安全检查补全了，这正是第 13 章插件安全审计清单的工具化方向。

已收录进手册第 13 章（配套工具）+ 生态章节：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/13-security.md

[truelove-dreamer]

你好， 感谢你对此项目的建议，你的三个建议都落地了，当前 v0.5.1（21 个单测全绿）： ① 豁免 → @deepseek-ai/*;豁免的同时记录内容哈希基线（$DSH_HOME/.dsh-plugin-vetting/baseline.json），安装包与基线不一致 → 豁免自动失效 + 报警。从"信任名字"变成"信任内容"。 ② 输出措辞：覆盖范围 报告每个包带 coverage: N file(s), M line(s) + lifecycle scripts: ... + deps: X declared, Y nested scanned, Z unchecked + 运行时表面（child_process/fetch/eval/socket 计数），边界显式可见。 ③ 第二层门禁 按你指的 tools/pre-execute 落点实现：config.gate: "deny-unvetted" 时，tools 管线拒绝调用门禁安装后注册的工具（即插件工具），除非在 allowlistTools 白名单。它覆盖"模型→插件工具"的调用面；插件进程内直接调 child_process/fetch/eval 不经过这道闸，那部分属于 harness 架构能力，已记录为 feature request 方向。门禁默认关。

[dongbeiboy]

怎么感觉是ai在互相头脑风暴

[shinjiyu]

试一下提示词注入他们