首页/ kiana/ Agent #Agent#研究#网络安全#DSH DSH插件生态安全：两篇观察文章的要点整理 整理日期：2026-11-02 研究定位：模型外围安全（agentic supply chain / plugin & tool poisoning） | | … kiana 2026-11-03 Agent研究 20 次阅读 > 整理日期：2026-11-02 > 研究定位：模型外围安全（agentic supply chain / plugin & tool poisoning） --- ## 1. 两篇文章摘要 | | 文章一 | 文章二 | |---|---|---| | 标题 | 我们拆了 1.1 万个 DeepSeek Harness 插件，发现官方几乎没有建立插件治理机制 | DeepSeek Harness 插件安全观察：我们扫描了 659 个插件，94.7% 属于高权限风险暴露 | | 来源 / 作者 | 雷峰网（作者 Rhea，编辑 李娜、岑峰） | AgentGuard AI Lab（工具厂商自述） | | 发布时间 | 2026-08-28 | 2026-09-07 | | 数据快照 | 2026-08-25 | 2026-09-02 | | 方法 | 生态普查 + 探针插件实测 + 源码审读 + 作者画像 | 分层抽样 + AgentGuard v1.1.29 静态扫描 | | 落点 | **治理机制缺失**（发现、信任、责任三层） | **权限暴露量化**（能力面 + 风险分级） | | 链接 | https://mp.weixin.qq.com/s/uvnELM-4n7kIbH-9MiuLVQ | https://mp.weixin.qq.com/s/RA_YW_ZMdaK_xEJOZDT2Yg | 两篇是互补的：文章一讲**为什么生态会失守**，文章二讲**失守的规模有多大**，这是一条完整的"外围供应链风险"论证链 --- ## 2.文章一：针对DSH生态社区的看法 ### 2.1 官方的一切皆插件思想，使得DSH生态的安全性边界减弱 ==插件的高权限使得投毒轻而易举== - 插件作为Agent的一部分，越过了工作区权限，这也是文章二所说，它们无恶意，但**具备投毒所需的能力面**，安全风险极高。 - 三档权限（仅读，工作区修改，完全权限）任何一档都无法约束插件行为，read-only 档下列出 `~/.ssh`、读到 API key、写 `/tmp`、连外网，九项试探三档全过。 - 官方自己的话：设计笔记写明"安全与权限不是设计目标"；自指工具集 README 自称"沙箱不是安全边界，请把这套工具当作 bash 权限对待"。 - 但是大部分用户不会注意这句警告。 ### 2.2 官方治理几乎为零 ==官方治理的缺失使得投毒可更加泛化== 官方对插件生态的全部指引只有 README / CONTRIBUTING 各一句：给仓库打上 `dsh-plugin` 标签。全站搜索后确认缺失： - 没有官方索引与背书 - 没有版本兼容矩阵 - 没有签名或校验 - 没有安全上报通道 - 没有官方推荐清单 GitHub 标签零门槛、零审批、与 dsh 无任何关系即可打；官方 README 的入口按"最佳匹配"（高度相关 star 数）排序，结果排第四的是一个 2020 年的简历生成器（靠六年攒的四万 star 蹭上来的）。 ### 2.3 命名混乱 ==可以通过伪装包名进行投毒== 抽 12 个"注册表上有、但没发布正式 npm 包"的插件去 npm 查同名：**5 个有同名包，逐个比对仓库与维护者，全部是另一个作者的另一个项目**。 后果：你想装作者 A 的 `dsh-hud`（得从 GitHub 装），顺手敲了 `dsh plugin add dsh-hud`，装到的是作者 B 的另一个 `dsh-hud`。 作者的评价很准：npm 早期的毛病是"名字先到先得"，但**至少只有一套名字**；dsh 是两套——发现靠 GitHub 标签和社区清单，安装靠 npm，**中间没有映射，也没有人负责对齐**。 --- ## 3.文章二：对生态的审查 ### 3.1 方法 | 项 | 内容 | | -------- | ------------------------------------------------------------ | | 数据快照 | awesome-dsh-plugin.com，2026-09-02，共 2,916 个插件，近 30 天下载量合计 3,885,362 | | 抽样 | 分层抽样 + 下载量覆盖补足（敏感类别头部、其他类别头部、近 7 天新上架、长尾随机），补足至 90% 覆盖 | | 样本 | 去重后 **659 个（占 22.6%）**，覆盖近 30 天下载量 **90.0%** | | 执行 | 590 个成功扫描；15 个覆盖不完整；54 个无法扫描 | | 可复核 | 每条结果记录 commit SHA 与 artifact SHA-256 | | 原则 | **fail-closed**：看不全就不给"安全"结论 | ### 3.2 能力面分布（605个插件） | 能力 | 占比 | 数量 | | ------------------- | ---- | ---- | | 文件读取 | 91% | 548 | | UI 注入 | 86% | 518 | | 文件写入 | 82% | 496 | | 环境变量访问 | 81% | 489 | | Provider / 模型路由 | 75% | 451 | | 网络访问 | 74% | 449 | | 持久化存储 | 74% | 445 | | Shell 执行 | 63% | 380 | | 会话访问 | 55% | 333 | | 工具注册表变更 | 48% | 293 | | 运行时变更 | 33% | 202 | ### 3.3 AUTO_UPDATE：真正的供应链入口 32 个插件被识别出"从远程获取内容并自动安装或执行"的代码模式，包括近 30 天下载量约 **20.4 万的 dsh-remote-web-ui**、约 **14.5 万的 modlens**、约 **5.1 万的 dsh-vision-router**。 这类行为在很多场景下是功能所需（加载远程组件、同步配置或价格表），**AUTO_UPDATE 本身不是漏洞**。但供应链含义是：用户信任的不只是安装时审查过的那份代码，还包括**未来经由该通道交付的内容**——作者账号、托管服务器或分发链路一旦被攻破，受影响的是全部装机用户。 --- ## 4.收获 ### 4.1 与 MCP 投毒研究的一一映射 | 文章里的现象 | 对应的已知攻击面（检索关键词） | | ---------------------------------------------- | ------------------------------------------------------------ | | 插件是DSH的一部分，绕过沙箱审查 | confused deputy / privilege boundary collapse；`MCP confused deputy` | | `dsh-tui` 皮肤插件静默改写沙箱策略 | **配置投毒 / policy tampering**（不是代码投毒，而是策略投毒） | | "auto" 档：分类器提示词写 "Default to approve" | 审批器的提示词即攻击面；`approval fatigue` / `LLM-as-judge 被绕过` | | 32 个 AUTO_UPDATE，含 20 万+ 下载量插件 | **rug pull** / 远程载荷 / `MCP server poisoning` 的更新通道版本 | | 12 抽 5 出现 npm 同名不同作者 | **name squatting / typosquatting / slopsquatting** | | 505 个 `deepseek-harness-desktop` 仓库 | 命名空间污染 → 供应链混淆 | | 工具注册表变更 48%、运行时变更 33% | 工具身份与注册表完整性（`tool shadowing` / registry trust） | 文章一、二天然构成了"非 MCP 协议的第三方插件生态"这一**平行样本**——做 MCP 工具投毒研究时，可以拿它当"同一威胁模型在不同协议下的复现"，而不是只引 MCP 自家论文。 ### 4.2 方向 - 文章二虽然做了审查，但只是静态的审查，扫描了插件市场的权限等级，并未对插件实际运行所涉及的流程进行研究，后续可以走动态的链路审查。 - 从供应链源头的攻击，在Agent的执行过程中如何被放大，有助于去发现隐藏攻击方式。 #Agent#研究#网络安全#DSH 复制链接 kiana @kianayang · 在蓝屿写作 关于博主
