DeepSeek Harness 插件安全清单（10 条）

安装一个 DeepSeek Harness（dsh）插件,意味着在你的机器上运行一段你自己没有写过的代码——安装期运行一次,之后每次插件的 apply() 函数执行时再运行一次。没有官方的插件审核流程,也没有市场会在你 dsh plugin add 之前替你审查任何东西。这份清单按照实际重要性排序,列出了在安装一个你没有亲自审查过的插件之前,值得检查的十件事。

为什么这件事比听起来更重要

dsh 自己的文档在这一点上说得异常直白。在描述 GitHub 来源插件的构建步骤可能需要的 allowBuilds 权限时,文档写得很清楚:

这个放行等价于:允许该包的代码在你机器上、于安装期执行,且脱离 agent 运行时的任何沙箱保护。只应该允许你信任其源码的包,并且要锁定到具体的 commit。

这条警告的适用范围远不止 allowBuilds——它对安装任何插件都成立,因为一个插件的 apply(ctx) 函数是以 Node.js 进程本身拥有的权限运行的,不受 dsh 运行时沙箱模式(read-only、workspace-write、danger-full-access)的约束。这些沙箱模式管的是agent 在一次会话中通过工具能做什么;它们管不了一个插件自己的代码在加载时能做什么。

1. 确认它真的是个插件,而不只是打了话题标签

打开仓库的 package.json,看有没有带 bundle 或 profile 子字段的 dsh 字段。一个仓库可以打上 dsh-plugin 这个 GitHub 话题标签,却不声明这个字段——那只是自我申报的标签,不是功能性信号。没有 dsh 字段,即使 pnpm 顺利把它装进去了,dsh plugin add 也不会激活它的任何配置。完整的发现渠道全景,见我们的寻找 DeepSeek Harness 插件指南。

2. 读一读 dsh.bundle 字段指向的 patch 文件

{ "dsh": { "bundle": { "patch": "./cordis.patch.yml" } } }

这个 cordis.patch.yml(或者它实际的文件名——路径是从字段里读出来的,不是固定文件名)是一份 YAML 列表,精确描述了这个插件在你的配置树里插入或覆盖了什么。读一遍它,能告诉你它加载了哪些模块、依赖哪些服务,以及——关键的一点——它是不是在覆盖一条已有的配置行,而不只是新增一行。一个 patch 会整体覆盖匹配到的 id 的 config 块,而不是深度合并,所以一次覆盖悄悄改变的东西,可能比它 README 里说的更多。

3. 检查 package.json 里的 prepare 脚本和依赖

prepare 脚本会在 GitHub 来源插件安装时自动运行(见下面第 5 点)。除此之外,看一下完整的 dependencies 列表——一个异常长的依赖树,或者跟插件声称的功能完全看不出关系的依赖,值得在安装前多看一眼。

4. 检查源码里对外的网络调用

一个调用工具或 LLM 适配器的插件需要网络访问才能工作——这是预期之内的。值得仔细审视的,是一个跟插件所声称功能毫无关系的端点调用,尤其是发生在模块加载或 apply() 阶段、而不是响应 agent 明确执行的某个动作时。可以先在源码里 grep 一下 fetch、http、https 或任何 HTTP 客户端的 import 作为起点。

5. 搞清楚 allowBuilds 到底授予了什么

GitHub 安装拉取的是源码,不是构建产物。如果一个插件需要 prepare 脚本来自己编译,pnpm 10+ 默认会拦截这个脚本,你会被要求在 profile 的 pnpm-workspace.yaml 里显式放行:

allowBuilds:
  dsh-hello-plugin: true

这是整个安装流程里杠杆效应最大的一刻——在 dsh 自己的沙箱能覆盖到任何东西之前,这是你唯一在授予任意代码执行权限的地方。我们的 GitHub 安装指南完整讲解了这个提示。

6. 锁定到 commit,而不是分支

dsh plugin --profile web add github:owner/repo#a1b2c3d

一个分支引用(或者默认的、未锁定的形式)意味着上游对同一分支后续的一次推送,会在你下次重装或更新时改变你机器上实际运行的代码——而你没有获得任何新的批准。commit SHA 是唯一真正不可变的锁定方式;tag 从技术上讲仍然可能被仓库所有者强制改指向。

7. 优先选择已发布到 npm、自带构建产物的插件(如果有的话)

一个发布到 npm 的插件直接自带编译好的产物,所以完全不需要 prepare 脚本,也就不需要做 allowBuilds 的决策——少了一个安装期代码执行的面。这也正是 dsh 官方文档给插件作者推荐的路径。如果你想要的插件两种形式都有,npm 版本是风险更低的安装选择。

8. 对新的或未审查过的插件,用 workspace-write 而不是 danger-full-access 来试

dsh 新会话的默认权限预设是 workspace-write + ask 审批——写操作被限制在会话工作区和平台临时目录内,风险动作会弹出审批提示。danger-full-access 则彻底移除了这两重约束。第一次试用一个不熟悉的插件时,留在默认预设上,而不要为了"让它跑起来"就切到 danger-full-access——如果一个插件只有在完全访问权限下才能工作,这件事本身就值得当作一个信号,先去调查原因,再决定要不要放行。预设具体如何工作,见我们的权限与沙箱指南。

9. 把新插件隔离在一个专用 profile 里

因为一个 profile 本质上就是一个目录,有自己的 bundle 列表和 cordis.patch.yml,在一个用完即弃的 profile 里(dsh plugin --profile scratch add ...)试用新的或不熟悉的插件,能让它跟你日常依赖的插件和配置隔离开来。如果出了问题,影响范围就是这一个 profile,而不是你的主力配置。

10. 把社区安全工具当成第二意见,而不是保证

有一小批社区插件专门用来帮忙做这类审查。dsh-security-audit 运行一次本地、只读的审计,覆盖配置、插件来源、会话和网络暴露面。dsh-plugin-check 针对 manifest 协议和 patch 格式跑健康检查,并标出已知的构建陷阱。dsh-mcpguard 专门扫描技能和 MCP 配置里的提示词注入模式、同形字符和隐藏的 Unicode。另外,一个叫 dsh-poison-guard 的插件——在社区讨论中被描述为一个基于 AST 的扫描器,用来检测混淆过的恶意代码(比如十六进制编码的 Buffer.from 调用、用 atob 隐藏的 URL 之类的模式)——在社区渠道里被提到过,但它没有出现在 FindHarness 自己的插件索引中,我们也没有独立核实过它。以上全部都是社区项目,不属于 dsh 本身,也没有一个是我们独立核实过的。 跑一个扫描器可以当作一个合理的第二意见;它不能替代你亲自去做上面第 1 到第 4 条。

被一份目录收录,不等于一次安全审查

被本站收录——无论是来自社区 awesome 列表的精选集合,还是来自 npm 和 GitHub 话题搜索的更广泛发现集合——意味着这个插件的 package.json 声明了真实的 dsh 字段、背后有一个能用的 GitHub 仓库。这是一个可发现性信号,不是一次安全审查。本站上的任何内容,都不能替代你在给一个插件放行 allowBuilds、或把它装进你依赖的 profile 之前,亲自读一遍它的源码。

FAQ

awesome 列表上收录的插件都可以放心安装吗？

任何列表——不管是社区维护的还是别的——都不代表安全审查。人工审核能过滤掉死链或不相关的仓库,但不会检查插件的代码到底做了什么。不管你是在哪里找到这个插件的,都应该套用这份清单。

安装插件过程中风险最高的一刻是什么？

在你还没读过的 GitHub 来源插件上放行 allowBuilds: true。这正是你在授权任意代码在你机器上执行、且脱离任何 dsh 沙箱的那个具体时刻。

workspace-write 模式真的能保护我免受恶意插件的侵害吗？

只能部分保护,而且只针对会话过程中agent 的行为——保护不了插件自己的代码在加载期或安装期做的事。插件的 apply() 函数以及任何安装期的 prepare 脚本,都是以 Node.js 进程自身的权限运行的,不受会话沙箱模式的影响。

一个 star 数很高的插件是不是就更值得信任？

star 数反映的是受欢迎程度,不是安全性。它顶多是一个弱信号,而且容易被刷。读一遍 patch 文件和插件真正的入口代码,比任何 star 数都更靠谱。

dsh-poison-guard 是 DeepSeek 官方的工具吗？

不是。它是一个在公开讨论中被提到的社区扫描器,不属于官方的 deepseek-ai/deepseek-harness 仓库,也没有出现在我们自己的插件索引里。任何第三方扫描工具——包括这个——都应该被当作未经核实的社区项目对待。

下一步

关于 GitHub 安装的具体机制,读从 GitHub 安装插件。关于这份清单引用的权限与沙箱模型,见DeepSeek Harness 中的权限与沙箱。如果你要把这套流程推广给不止一个人使用,团队环境下运行 DeepSeek Harness讲了那个规模下的插件审批策略。