【DeepSeek Harness 研究】进化方向3：插件生态治理思考、设计与实现

deepseek harness 进化方向3：插件生态治理思考、设计与实现

作者：DeepSeek Harness

代码：https://gitee.com/ZachPineappleman/dsh_plugin_verify.git

DeepSeek Harness Evolution 3: Plugin Ecosystem Governance --- Trust Engineering, Design, and Implementation

摘要

大语言模型（LLM）agent 的快速普及带来了一个被普遍低估的安全问题：agent 插件生态的信任治理 。以 DeepSeek Harness（dsh）为代表的 agent harness 采用"一切皆插件"架构，第三方插件以同进程同权限 方式注入宿主，且插件是可执行代码与 LLM 指令（SKILL.md/prompt）的混合体 ------这一形态使现有面向纯代码包的供应链安全方案（SBOM、签名、SLSA）与面向纯文本的提示注入检测均存在审计盲区。与此同时，生态观察显示：dsh 社区已有 30+ 个市场/审计插件高度同质化，但官方治理层（统一质量/安全标准、深度静态扫描、签名验证、版本兼容检测）完全缺失；AI 批量生成使插件市场面临"垃圾场化"（柠檬市场均衡极端化）与"供应链军火库"（技能投毒、幻觉依赖）双重风险。

本文提出并实现了 dsh 插件生态的信任工程框架 与验证器 dsh-plugin-verify，贡献包括三个创新点：N1 双载荷静态审计 ------将插件代码载荷（危险 API、安装脚本、网络外联、混淆）与 prose 载荷（prompt injection、权限提升、幻觉依赖名）统一进同一风险模型，填补"代码包检测"与"技能投毒检测"之间的空白；N2 复合信任评分 ------对齐 OpenSSF Scorecard 的四维加权评分（A-D 级）与一票否决机制，含抗刷设计；N3 持续信任与更新重验 ------发布者身份锚定 + 每次更新强制重验 + 变更 diff 审计，正面回应"审核通过 ≠ 持续可信"的更新管道攻击。实现上，dsh-plugin-verify 以纯插件形态（不侵入 dsh 内核）提供 manifest 校验（含 typosquatting 相似度检测）、四维评分、双载荷扫描、可插拔签名验证（minimal-ecdsa 默认 + Sigstore 预留）、版本兼容检测与 CI 门禁（--gate）。评估表明：恶意样本（代码投毒 + SKILL.md 注入）被检出 9 项高危并触发一票否决，良性样本零高危，52 项单元/集成测试全绿。

关键词：agent harness；插件生态治理；供应链安全；双载荷静态审计；信任评分；技能投毒；typosquatting；DeepSeek Harness

1 引言

1.1 背景：agent 插件生态的信任困境

LLM agent 已经从"对话工具"演变为"自主行动体" $R4$ $R5$ 。为了扩展 agent 的能力，主流的 agent harness（包括 DeepSeek Harness、Claude Code、opencode 等）普遍采用插件机制：第三方开发者以 dsh plugin add <pkg> 的形式安装插件，插件注入宿主进程，获得与宿主相同的文件系统、网络、子进程与凭据访问权限。

dsh 生态的现状（来源：reference_notes/02-awesome-dsh-plugin学习笔记.md、digests/A4-现有市场审计插件对比.md）：

生态已爆发但治理缺位 ：awesome-dsh-plugin 收录数百个插件、14 个分类，市场/管理器类插件已有 30+（dsh-market、dsh-store、dsh-plugin-mall、dsh-plugin-manager×5、dsh-plugin-audit、dsh-insight、dsh-feed、dsh-recipe 等），功能高度同质化，各自定义评分体系，无官方统一标准。
官方能力空白 ：dsh plugin 命令（apps/cli/src/plugin.ts，158 行）仅是 pnpm 转发器------负责初始化 profile、在 profile 目录执行 pnpm、按 dsh.bundle 声明协调组合包列表。无质量评分、无静态安全扫描、无签名验证、无版本兼容检测。
安全警告是生态共识：awesome-dsh-plugin README 顶部明确警告"安装插件会在你的机器上以你自己的权限运行第三方代码......出现在此列表不是安全审查"。

这一现状与社区批评高度吻合：言论①《Harness 不会是未来》直言"开放插件生态 = 供应链攻击军火库 "（插件同进程同权限、无沙箱）；Skill Hub 的垃圾场化教训（AI 批量生成空壳技能）则揭示了"零成本上传 + 信息不对称 → 劣币驱逐良币"的治理经济学必然。MCP 生态的演进也印证了同一判断："协议层已就绪，信任层才是硬仗 "（来源：reference_notes/05-言论观点与理论搜索.md）。

1.2 问题陈述

本文聚焦三个研究问题：

RQ1（双载荷如何统一审计）：dsh 插件是代码与 LLM 指令的混合体，如何把面向纯代码包的供应链检测与面向纯文本的提示注入检测统一进一个可执行的静态审计模型？
RQ2（无边界执行下如何复合信任）：在"插件同进程同权限、无运行时边界"的约束下，装之前的信任决策需要哪些互补的证据（评分/扫描/签名/兼容），如何组合成一票否决与加权分并存的复合模型？
RQ3（评分如何抗刷与持续）：如何设计抗刷的评分（防刷分、防信号通胀）与持续信任机制（更新重验、发布者身份锚定）？

1.3 贡献

N1 双载荷静态审计 ：提出代码载荷 + prose 载荷统一风险模型，并实现 scan-code/scan-prose 两套规则引擎。
N2 复合信任评分：四维加权（维护/文档/生态/安全，权重可配）+ A-D 分级 + 独立一票否决。
N3 持续信任与更新重验：可插拔签名验证（minimal-ecdsa + Sigstore 预留）+ 更新重验设计。
工程交付 ：dsh-plugin-verify 纯插件实现（CLI + SDK + 报告 + CI 门禁），52 项测试全绿。
治理定位：明确"官方治理层（下游）vs 社区市场层（上游）"的差异化分工，为生态收敛提供统一标尺。

1.4 论文组织

第 2 章相关工作（供应链安全 / 治理经济学 / 插件生态实践 / Agent 专项风险）；第 3 章理论基础（dsh 插件机制现状、生态现状、四大 Gap）；第 4 章系统设计（架构、五阶段流水线、CLI/SDK）；第 5 章核心创新点（N1/N2/N3）；第 6 章实现；第 7 章评估；第 8 章讨论；第 9 章结论与展望。

2 相关工作

2.1 软件供应链安全

开源软件供应链攻击已是被系统研究的现实威胁。 $R12$ （Backstabber's Knife Collection, DIMVA 2020）与 $R13$ （Towards Measuring Supply Chain Attacks, 2020）对 npm/PyPI/RubyGems 的恶意包做了奠基性测量； $R14$ （SoK: Taxonomy of Attacks, IEEE S&P 2023）建立了 93 种攻击模式 × 99 个案例的系统分类学，可用于验证器的威胁模型清单。近期工作聚焦检测方法： $R15$ （DONAPI, USENIX Security 2024）用行为序列知识图谱检测恶意 npm 包； $R16$ （Malicious Package Detection using Metadata, WWW 2024）与 $R17$ （Beyond Typosquatting: Package Confusion, USENIX Security 2023）证明元数据（含包名相似度）可大规模检测 typosquatting/包混淆------本工作的 typosquatting 检测直接对齐 $R17$ 思路； $R18$ （Taint-Based Code Slicing for LLMs-based Malicious NPM Package Detection, 2025）与 $R19$ （ProfMalPlus, 2026）探索 LLM 辅助的恶意包分析，说明"LLM × 供应链检测"是前沿交叉。

供应链信任基础设施 ： $R20$ （SLSA）提供 provenance 分级框架； $R21$ （OpenSSF Scorecard）提供开源项目安全健康度评分（本工作 N2 的直接对标）； $R22$ （sigstore/cosign）提供 keyless 软件签名； $R23$ （Why Software Signing (Still) Matters, 2025）警示签名实践的分发信任边界问题------签名机制存在 ≠ 被正确使用。 $R24$ （SPDX 3.0）与 $R25$ （CycloneDX）定义 SBOM 格式。关键观察 ：这些方案假设"加载后仍有边界或可吊销"，而 agent 插件是同进程同权限注入、无运行时边界------这是本工作 Gap 1 的理论基础。

2.2 平台治理与信誉系统

Akerlof 的柠檬市场理论 $Rn-ek$ （The Market for "Lemons", 1970）奠定了信息不对称下劣质品驱逐优质品的理论基础------零成本上传 + AI 批量生成使这一均衡在插件市场极端化（来源：digests/A3-生态治理经济学调研.md）。平台的标准制度回应有三类：信号/认证（Spence 1973 信号理论）、筛选/门槛（审核流程）、声誉机制（评分评论）；三者成本结构不同，且信号本身可被操纵。近期平台治理研究（ $Rn-gov$ 等，2023--2026）关注 AI 生成垃圾内容对平台质量的冲击------与本工作的"幻觉依赖名/slopsquatting 检测"直接相关。

2.3 插件生态治理实践

浏览器扩展与 IDE 扩展是最近的参照系： $Rn-cws$ （Chrome Web Store 恶意扩展研究）证明更新管道是攻击面------16+ 扩展被攻破、320 万+ 用户受影响，"审核通过 ≠ 持续可信"； $Rn-vscode$ （VS Code Verified 徽章绕过）说明发布者身份锚定不足。这些实践直接支撑本工作 N3（持续信任与更新重验）的设计动机。

2.4 Agent 生态特有风险：技能投毒与双载荷攻击

2025--2026 年出现了专门针对 agent 技能（skill）/插件的投毒研究，是本文 N1 最直接的相关工作：

$Rn-badskill$ （BadSkill, 2026, arXiv:2604.09378）：技能 = 代码 + 指令混合体，可同时携带恶意代码与诱导模型行为的指令（后门投毒）。
$Rn-steer$ （Dependency Steering，见 $Rn-skillauth$ / $Rn-skillject$ 同族 2026 研究）：恶意技能可诱导 agent 选择恶意依赖（幻觉依赖的主动利用）。
$Rn-harmless$ （中性措辞隐蔽引导幻觉，2026）：提示注入检测不能只匹配明显恶意词。
$Rn-cloak$ （Cloak and Detonate 类扫描规避研究，2026, arXiv:2607.02357）：恶意技能可规避静态扫描（混淆/延迟执行），需要动态检测配合。
$Rn-mcpsec$ / $Rn-mcpserver$ / $Rn-mcpparasitic$ （MCP 工具服务器安全 2025--2026）：MCP 生态投毒的系统测量。
$Rn-halluc-pkg$ / $Rn-halluc-import$ / $Rn-halluc$ （包幻觉 2024--2026）：代码生成 LLM 幻觉依赖的系统分析与再评估。

相关工作的空白 ：上述技能投毒研究聚焦攻击面分析 （攻击如何生效），尚未与包管理生态的恶意代码检测 融合为统一的"双载荷静态审计工具链"------这正是本工作 N1 的切入位置（来源：digests/A6-研究Gap与论文大纲.md）。

3 理论基础：dsh 插件生态现状与 Gap

3.1 dsh 插件机制盘点

依据 digests/A1-插件机制盘点.md 与源码研读，dsh 插件的安装-加载-运行时全链路如下：

环节	机制	现状
安装	`dsh plugin --profile <name> add <pkg>`（`apps/cli/src/plugin.ts`，158 行）	纯 pnpm 转发器：初始化 profile → pnpm 链接 → 按 `dsh.bundle` 协调 bundles 列表。无评分/扫描/签名/兼容
声明	`package.json` 的 `dsh` 字段：`dsh.profile`（profile 的 bundles 列表）/ `dsh.bundle`（组合包的 patch 文件）	已有完整机制（来源：`docs/user/develop/basic/publish.zh.md`）
加载	Cordis Loader + include/group/HMR；`boot()` 断言加载与激活（来源：`packages/boot/app-boot/README.zh.md`）	加载期无安全检查
运行时	插件注入宿主进程，同进程同权限；`ctx` 提供服务访问	无运行时沙箱（沙箱只约束 agent 的工具调用，不约束插件代码）
清单	`plugin-inventory`（宿主插件清单，只读投影）	已有，无安全元数据

关键结论（A1） ：dsh 插件机制的"安装/加载/运行时"已完整，但治理层（评分/扫描/签名/兼容）完全缺失 ------这正是官方该补位的空白（来源：digests/A1-插件机制盘点.md）。

3.2 生态现状与差异化定位

依据 digests/A4-现有市场审计插件对比.md 与 reference_notes/02-awesome-dsh-plugin学习笔记.md：

30+ 市场/管理器同质化：dsh-market、dsh-store、dsh-plugin-mall、dsh-plugin-manager（×5 同名）、dsh-plugin-audit、dsh-insight、dsh-feed、dsh-recipe、dsh-need-finder 等，功能高度重叠（浏览/安装/推荐/评分）。
社区工具各自为政 ：dsh-plugin-audit 有"维护/文档/npm/生态"四维评分 + 高危一票否决；dsh-insight 有健康评分 + 静态扫描------但无统一标准。
官方差异化定位 ：官方做治理层（下游） ------验证/评分/扫描/签名/兼容，输出统一标尺；社区做市场层（上游） ------消费治理层输出。治理层不与市场层竞争（来源：digests/A4 结论）。

3.3 四大研究 Gap

Gap 1：无边界执行模型下的"加载时信任决策"缺口。 dsh 插件 = 注入宿主进程的 Node.js 模块（同进程同权限、无沙箱），信任一旦建立即获宿主全部权限。现有方案（SBOM/签名/SLSA）假设"加载后仍有边界或可吊销"，无针对 agent harness 插件的复合信任方案（静态扫描 + 签名 + 安装门禁）。支撑： $R12$ $R14$ $R20$ $R22$ $R23$ 。

Gap 2：代码 + LLM 指令双载荷的检测维度缺失（核心创新点）。 dsh 插件 = 可执行代码 + 可能含 LLM 指令/技能描述的混合体。现有恶意包检测面向纯代码包；技能投毒研究（ $Rn-badskill$ $Rn-steer$ $Rn-harmless$ $Rn-cloak$ ）未与包管理恶意代码检测融合。verify 需统一的"双载荷静态审计"。

Gap 3："审核通过 ≠ 持续可信"的更新管道信任缺口。 Chrome 扩展发布通道被攻破、VS Code Verified 徽章被绕过------攻击面在更新管道与发布者账号。现有生态缺乏"发布者身份锚定 + 每次更新强制重验 + 变更 diff 审计"的持续信任机制。支撑： $Rn-cws$ $Rn-vscode$ $R23$ 。

Gap 4：AI 垃圾内容与幻觉依赖对开放生态的污染缺口。 Skill Hub 垃圾场化（54% 零 star、基尼 0.983）；slopsquatting（20 万+ 可注册幻觉包名）； $Rn-halluc$ 显示前沿模型幻觉包名率仍达 2.2%--5.2%。现有信誉系统（star/下载量）可被刷；provenance 只证来源不证质量。需要"抗刷评分 + 来源真实性 + 幻觉依赖检测"组合治理。支撑： $Rn-ek$ $Rn-gov$ $Rn-halluc$ 。

3.4 三大创新点（回应 Gap）

创新点	内容	回应 Gap
N1 双载荷静态审计	同时扫描代码载荷（危险 API/postinstall/外联/混淆）与 prose 载荷（prompt injection/权限提升/幻觉依赖名），输出统一风险模型	Gap 2
N2 复合信任评分（A-D 级）	对齐 Scorecard 四维加权 + 硬性一票否决 + 抗刷设计（真实性校验/发布者身份锚定）	Gap 1/4
N3 持续信任与更新重验	发布者身份锚定 + 每次更新强制重验 + 变更 diff 审计	Gap 3

4 系统设计：dsh-plugin-verify 架构

4.1 设计原则

复用不重造：包名/版本/semver 语义对齐 npm 生态约定（自有最小实现避免安装负担）；报告模式对齐 benchmark-plugin（进化2）。
不侵入内核 ：独立 CLI + 可选 Cordis 插件入口；不修改 packages/。
离线优先：基础校验/评分/扫描全离线；签名验证与漏洞库更新可联网（默认跳过联网）。
双载荷审计（N1）：code + prose 统一风险模型。
fail-closed（N2）：高危/恶意/签名失败/license 缺失直接 fail。
可插拔签名（N3）：验证器接口 + minimal-ecdsa（默认）+ Sigstore 预留。
抗刷评分：权重可配、规则公开、一票否决独立于加权分。

4.2 总体架构

图 1：五阶段流水线（manifest → score → scan → signature → compat → verdict → report）。输入源支持本地目录/tarball/包名；输出 JSON/Markdown；CLI/SDK 双入口；治理层在下游，市场层在上游消费。

五阶段流水线：

阶段	模块	职责
① manifest 校验	`manifest.ts`	package.json 必填、dsh.bundle/patch、命名规范 + typosquatting 相似度
② 四维评分	`score.ts`	维护/文档/生态/安全 0-100 → A-D 级；权重可配；一票否决独立
③ 双载荷扫描	`scan.ts`	`scan-code`（代码载荷）+ `scan-prose`（指令载荷）
④ 签名验证	`signature.ts`	可插拔 backend：minimal-ecdsa / sigstore（预留）
⑤ 兼容检测	`compat.ts`	semver 范围 vs dsh/Node 版本 → 兼容/可能兼容/不兼容/未知

4.3 用例模型与 CLI/SDK

CLI：

复制代码

dsh-plugin-verify verify <path> [--gate] [--format json|markdown] [--no-prose] [--no-signature]
dsh-plugin-verify verify-all <dir> [--gate] [--format json|markdown]

退出码：0 通过 / 1 存在高危或失败（--gate）/ 2 参数错误 / 3 崩溃。

SDK：

ts 复制代码

import { verifyPlugin, verifyPlugins } from 'dsh-plugin-verify'
const result = await verifyPlugin('./my-plugin', { gate: true })
// result.verdict ('pass'|'warn'|'fail') · result.score.grade ('A'-'D')
// result.scan.codeFindings / result.scan.proseFindings · result.summary.high

dsh 集成 ：cordis.patch.yml 声明 dsh.bundle，经 ctx.commands 注册 verify 人类命令（可选，核心能力不依赖 Cordis 运行时）。

5 核心创新点

5.1 N1：双载荷静态审计（代码 + LLM 指令统一风险模型）

图 2：dsh 插件 = 代码载荷 + prose 载荷混合体。左：代码载荷检测（危险 API/安装脚本/外联/混淆，对齐恶意包检测研究）；右：指令载荷检测（prompt injection/权限提升/幻觉依赖名，对齐技能投毒研究）。两类发现统一为 Finding\[\] 风险模型。

动机：dsh 插件是"可执行代码 + LLM 指令"的混合体（来源：plugin-verify/src/scan.ts）。现有恶意包检测（ $R15$ $R16$ $R17$ ）面向纯代码包，不识别 SKILL.md/prompt 中的指令注入；技能投毒研究（ $Rn-badskill$ $Rn-steer$ $Rn-harmless$ $Rn-cloak$ ）证明 prose 载荷可诱导模型执行恶意依赖、泄露信息、绕过审批------忽略任一载荷即存在审计盲区。

代码载荷规则（scan-code）：

规则	级别	对应攻击模式（ $R14$ 分类学）
子进程执行（exec/spawn/fork）	high	任意命令执行
eval / Function 构造器	high	动态载荷隐藏
安装脚本（postinstall/preinstall/install）内容	high/medium	安装期投毒
网络外联 / 硬编码 IP	high/medium	C2 / 数据外发
敏感环境变量读取（KEY/TOKEN/SECRET/PASSWORD）	high	凭据窃取
Base64 编解码 / 超长单行	medium	混淆载荷
管道执行远程脚本（curl \| bash）	high	经典投毒手法

指令载荷规则（scan-prose） ：prompt injection 特征（指令覆盖/套取系统提示词/越狱）、权限提升指令（全权限/跳过审批/不询问用户）、数据外发指令、疑似幻觉依赖名（slopsquatting 候选）。设计上对齐 $Rn-harmless$ 的教训：不只匹配明显恶意词，还检测"中性措辞 + 权限/外发意图"的组合。

统一风险模型 ：两类载荷输出统一 Finding[]（id/level/category/title/detail/location/suggestion），供评分 security 维度消费，一票否决共享同一门槛。

5.2 N2：复合信任评分（四维加权 + A-D 级 + 一票否决）

图 3 左：四维加权评分（维护性 0.3/文档 0.2/生态 0.2/安全 0.3）→ 0-100 → A/B/C/D 级；一票否决（高危/恶意/签名失败/license 缺失）独立于加权分。右：dsh 插件攻击面------同进程同权限，文件系统/凭据/网络/子进程/LLM 指令五面暴露，现有 SBOM/签名方案存在缺口（Gap 1）。

对齐 OpenSSF Scorecard（ $R21$ ）：0-100 加权聚合、规则公开、可复现。差异在于------

维度调整：Scorecard 面向开源项目仓库；本模型面向"可安装插件"，故用"维护性/文档/生态活跃/安全"四维（对齐 dsh-plugin-audit 的四维但官方化）。
一票否决独立 ：高危扫描发现/恶意特征/签名失败/license 缺失 → 直接 fail，不可被高分抵消（fail-closed）。这是与纯加权评分的本质区别：加权分描述"综合质量"，一票否决描述"安全底线"。
抗刷设计 ：权重可配（VerifyOptions.weights）、规则公开可复现、一票否决不可刷（恶意/高危不可通过刷 star/下载量抵消）。回应 Gap 4 的"信号通胀"风险（来源：digests/A3-生态治理经济学调研.md）。

5.3 N3：持续信任与更新重验

图 4：信任生命周期------首次上架（N1/N2 静态评估）→ 签名发布（发布者身份锚定）→ 安装运行（B 阶段展望：运行时隔离）→ 版本更新（攻击面）→ 强制重验（每次更新重跑 verify + 变更 diff 审计）。

动机： $Rn-cws$ 证明 Chrome 扩展 16+ 更新管道被攻破、320 万+ 用户受影响； $R23$ 警示签名分发信任边界被绕过； $Rn-vscode$ 说明 Verified 徽章可被绕过------首次上架审核无法覆盖后续每次更新。

机制：

发布者身份锚定 ：签名绑定 keyId（signature.ts 的 .dsh-signature.json 记录 signature/keyId/algorithm）。
每次更新强制重验 ：verify-all --gate 集成 CI，更新即重扫。
变更 diff 审计：版本间差异聚焦（新增高危 API / 新 prose 注入 → 阻断）。
签名失效即降级：更新后签名不匹配 → 拒绝运行（fail-closed）。

实现为可插拔验证器接口：

ts 复制代码

interface SignatureVerifier {
  name: string
  verify(opts: { content: string; signature?: string; publicKey?: string; keyId?: string }): Promise<SignatureResult>
}
// minimal-ecdsa（默认）：自建 P-256 ECDSA，零依赖、离线可测
// sigstore（预留）：SIGSTORE 环境变量存在时启用 keyless 验证

6 实现

6.1 模块与技术决策

plugin-verify/ 目录结构（来源：plugin-verify/）：

复制代码

plugin-verify/
├── package.json          # dsh.bundle 声明（可经 dsh plugin add 安装）
├── cordis.patch.yml      # 可选 dsh verify 命令入口
├── DESIGN.md             # 设计文档
├── bin/dsh-plugin-verify.js  # CLI bin（优先 lib，开发经 tsx）
├── src/
│   ├── types.ts          # 共享类型（Finding/ScoreResult/VerifyResult...）
│   ├── manifest.ts       # manifest 校验 + typosquatting（Levenshtein）
│   ├── score.ts          # 四维评分 A-D 级 + 一票否决
│   ├── scan.ts           # 双载荷扫描（scan-code + scan-prose）
│   ├── signature.ts      # 可插拔签名验证（minimal-ecdsa + sigstore 预留）
│   ├── compat.ts         # 版本兼容 + 内置最小 semver
│   ├── report.ts         # JSON/Markdown 报告（SARIF 预留）
│   ├── index.ts          # SDK（verifyPlugin/verifyPlugins）
│   └── cli.ts / cli-entry.ts  # CLI 与 dsh 命令入口
└── tests/                # 6 个测试文件，52 项用例

技术决策：

零外部依赖：全部自研（最小 semver、最小 ECDSA、Levenshtein），避免插件本身成为供应链风险------与 $R23$ 的"签名工具自身可信"精神一致。
ESM + NodeNext ：对齐 dsh 包规范（type: module、allowImportingTsExtensions 开发模式、rewriteRelativeImportExtensions 构建）。
复用 benchmark-plugin 骨架 ：bin 双路径（lib/tsx）、vitest 配置、dsh.bundle 声明。

6.2 typosquatting 检测（manifest）

对齐 $R17$ （Beyond Typosquatting: Package Confusion）思路：与已知官方包名（DEFAULT_KNOWN_OFFICIAL，30 个 dsh 官方包）做归一化（去分隔符）+ Levenshtein 编辑距离比对，距离 ≤2 或相对距离 ≤20% 即告警。区分同名（不算）与仿冒（告警）。

6.3 最小 semver 实现（compat）

支持 ^、~、>/>=/</<=/=、|| 或范围、连字符范围、部分版本段（>=20、~1、^2）。测试覆盖 11 项（tests/compat.spec.ts）。

6.4 测试体系

tests/ 6 个文件 52 项：manifest（合法性/typosquatting/编辑距离）、scan（代码载荷 6 类 + prose 载荷 4 类检出 + 良性误报控制）、score（分级/一票否决/权重）、signature（签名/篡改/伪造/未签名四态）、compat（11 项）、integration（恶意/良性端到端 + CLI --gate 退出码 + 批量）。

7 评估

7.1 方法

构造两类样本（tests/integration.spec.ts）：

恶意样本 （evil-plugin）：代码载荷（postinstall 外联 curl http://192.168.1.1/x | bash、eval、敏感 env 读取、硬编码 IP）+ prose 载荷（SKILL.md 指令覆盖/套取系统提示词/数据外发指令）。
良性样本 （good-plugin）：正常插件（无高危 API、README 完整、无注入指令）。

评估指标：恶意检出（高危发现数与一票否决触发）、良性误报（高危数）、CLI --gate 退出码、测试通过率。

7.2 结果

指标	结果
恶意样本高危发现	9 项（安装脚本外联/eval/敏感 env/硬编码 IP/指令覆盖/套取提示词/数据外发等）
恶意样本评分	D 级（42 分），安全维度 0 分，一票否决触发
恶意样本 `--gate` 退出码	1（阻断）
良性样本高危	0 项
良性样本评分	B 级（74 分）
良性样本 `--gate` 退出码	0（放行）
自动化测试	52/52 通过（6 文件）
双载荷覆盖	code 6 类规则命中 + prose 4 类规则命中（统一 Finding\[\]）

7.3 分析

双载荷审计有效：恶意样本的代码载荷与 prose 载荷均被独立检出，且两类发现进入同一报告与评分------验证了 N1 的"统一风险模型"设计。若只做代码扫描（现有方案），SKILL.md 的注入指令将被漏检；若只做 prose 检测，postinstall 外联将被漏检。
一票否决语义正确：安全维度 0 分 + 综合分 42 分（D 级）但即使其他维度高分也不改变 fail 结论------验证了 N2 的"加权分描述质量、一票否决描述底线"分层。
CI 门禁有效 ：--gate 对恶意返回 1、对良性返回 0，可直接集成流水线。

7.4 局限

样本规模小（2 个样本），误报率需更大样本集评估（未来工作）。
静态扫描固有局限：混淆/延迟执行可规避静态检测（ $Rn-cloak$ 的教训）------需动态检测/运行时监控配合（对应方向 4 安全加固与 B 阶段信任层）。
幻觉依赖名检测为粗筛：基于已知包名集合的启发式，需接入真实 npm 注册表查询（离线优先约束下暂未启用）。

8 讨论

8.1 与 OpenSSF Scorecard / SLSA / sigstore 的关系

本工作的 N2 评分模型对齐 $R21$ （Scorecard）的"规则公开、加权聚合、可复现"精神，但针对可安装插件调整了维度（维护/文档/生态/安全）并引入"一票否决独立于加权分"的底线语义------Scorecard 是加权分，本模型是"加权分 + 底线"双层。N3 的签名设计对齐 $R22$ （sigstore keyless）与 $R20$ （SLSA provenance），但增加"更新重验"------因为 $R23$ 证明签名机制存在 ≠ 被正确使用，且 agent 插件的更新管道是主要攻击面（ $Rn-cws$ ）。

差异的本质 ：这些标准面向"构建-发布-分发"的通用供应链；本工作面向"同进程注入、无运行时边界"的 agent 插件------加载时信任决策是唯一防线，故需复合证据（评分 + 扫描 + 签名 + 兼容）与 fail-closed 门禁。

8.2 治理层 vs 市场层：生态分工

本工作的定位是治理层（下游） ：输出统一标尺（评分/安全状态/兼容性），供 30+ 社区市场（dsh-market、dsh-insight 等）消费。这避免了"官方再造一个市场"的红海竞争（来源：digests/A4-现有市场审计插件对比.md），并回应了生态碎片化------所有市场消费同一官方标尺，用户不再困惑"该信哪个评分"。

8.3 对言论①批评的回应

言论①《Harness 不会是未来》批评"开放插件生态 = 供应链攻击军火库"（插件同进程同权限、无沙箱）。本工作的回应分两层：

本阶段（静态信任评估）：verify 在装之前做双载荷扫描 + 复合评分 + 签名验证------"军火库"至少先过安检（回应静态面）。
B 阶段（供应链信任执行，展望）：插件沙箱/隔离执行 + 运行时监控 + 安装审计------真正解决"同进程同权限"（回应动态面，属方向 4 安全加固与方向 3 二期）。

8.4 局限

静态扫描固有盲区：混淆/延迟执行/运行时下载的恶意载荷可规避静态检测（ $Rn-cloak$ ）------需动态检测（B 阶段）。
幻觉依赖检测的离线约束：启发式粗筛误报较高，需联网核验（未来工作）。
评分的主观性：维护性/文档等维度依赖文件特征推断，与真实使用体验有差距。
样本集规模：评估样本有限，检出率/误报率需更大规模验证。
签名信任根 ：minimal-ecdsa 的公钥信任根（~/.dsh/trusted-keys/）需人工配置，生产环境应过渡到 Sigstore 透明日志。

9 结论与展望

9.1 结论

本文针对 agent harness 插件生态的信任治理问题，提出了信任工程框架 并实现了验证器 dsh-plugin-verify。核心贡献可概括为三点：

N1 双载荷静态审计：把"代码包检测"与"技能投毒检测"两个此前割裂的研究线统一进同一风险模型------这是对 dsh 插件"代码 + LLM 指令混合体"形态的直接回应，也是现有恶意包检测工具（面向纯代码）与提示注入检测工具（面向纯文本）之间的空白填补。
N2 复合信任评分："加权分描述质量、一票否决描述底线"的分层模型，对齐 Scorecard 但强化了 fail-closed 语义。
N3 持续信任与更新重验：把信任从"一次性审核"扩展为"生命周期管理"，正面回应更新管道攻击。

工程上，dsh-plugin-verify 以纯插件形态交付（不侵入内核、零外部依赖、CLI/SDK 双入口、CI 门禁），52 项测试全绿，恶意/良性样本端到端验证通过。生态上，它确立了"官方治理层 + 社区市场层"的差异化分工，为 dsh 插件生态收敛提供统一标尺。

9.2 展望

B 阶段（信任层执行）：插件沙箱/隔离执行（worker_threads/子进程/容器）+ 运行时行为监控 + 安装审计------真正解决"同进程同权限"。
动态双载荷检测：结合 $Rn-cloak$ 的动态检测思路，对可疑插件做沙箱内动态执行分析。
漏洞库与幻觉依赖联网核验：接入 OSV/真实 npm 注册表，提升幻觉依赖检测精度。
评分进化：引入下载量/社区反馈等真实信号（需防刷），对齐 $R21$ 的持续演进。
生态集成：与 dsh-market 等市场插件对接，输出统一评分徽章（类似 Scorecard badge）。

参考文献

$R12$ M. Ohm, H. Plate, A. Sykosch, M. Meier. Backstabber's Knife Collection: A Review of Open Source Software Supply Chain Attacks. DIMVA 2020. arXiv:2005.09535.

$R13$ R. Duan, O. Alrawi, R. P. Kasturi, et al. Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages. 2020. arXiv:2002.01139.

$R14$ P. Ladisa, H. Plate, M. Martinez, O. Barais. SoK: Taxonomy of Attacks on Open-Source Software Supply Chains. IEEE S&P 2023. arXiv:2204.04008.

$R15$ C. Huang, et al. DONAPI: Malicious NPM Packages Detector using Behavior Sequence Knowledge Mapping. USENIX Security 2024. arXiv:2403.08334.

$R16$ S. Halder, M. Bewong, A. Mahboubi, et al. Malicious Package Detection using Metadata Information. WWW 2024. arXiv:2402.07444.

$R17$ S. Neupane, G. Holmes, E. Wyss, D. Davidson, L. De Carli. Beyond Typosquatting: An In-depth Look at Package Confusion. USENIX Security 2023.

$R18$ D.-K. Nguyen, G.-T. Ho, Q.-M. Pham, et al. Taint-Based Code Slicing for LLMs-based Malicious NPM Package Detection. 2025. arXiv:2512.12313.

$R19$ Y. Huang, Z. Zhao, B. Chen, et al. ProfMalPlus: Agent-Coordinated Detection of Malicious NPM Packages via Static-Dynamic Analysis Synergy. 2026. arXiv:2607.13965.

$R20$ SLSA（OpenSSF 规范）. Supply-chain Levels for Software Artifacts , v1.0（2023-04）. slsa.dev；配套学术论文：Unraveling Challenges with SLSA for Securing the Software Supply Chain. 2024. arXiv:2409.05014.

$R21$ N. Zahan, P. Kanakiya, B. Hambleton, S. Shohan, L. Williams. OpenSSF Scorecard: On the Path Toward Ecosystem-Wide Automated Security Metrics. IEEE Security & Privacy Magazine 2023, 21(4). arXiv:2208.03412.

$R22$ Z. Newman, J. S. Meyers, S. Torres-Arias. Sigstore: Software Signing for Everybody. ACM CCS 2022. DOI: 10.1145/3548606.3560596.

$R23$ K. G. Kalu, J. C. Davis. Why Software Signing (Still) Matters: Trust Boundaries in the Software Supply Chain. 2025. arXiv:2510.04964.

$R24$ SPDX. SPDX Specification 3.0. spdx.dev.

$R25$ CycloneDX. CycloneDX Specification. cyclonedx.org.

$Rn-badskill$ BadSkill: Backdoor Attacks on Agent Skills via Model-in-Skill Poisoning. 2026. arXiv:2604.09378.

$Rn-skillject$ SkillJect: Effectively Automating Skill-Based Prompt Injection for Skill-Enabled Agents. 2026. arXiv:2602.14211.

$Rn-skillinject$ SKILL-INJECT: Measuring Agent Vulnerability to Skill File Attacks. 2026. arXiv:2602.20156.

$Rn-skillauth$ Towards Secure Agent Skills: Architecture, Threat Taxonomy, and Security Analysis. 2026. arXiv:2604.02837.

$Rn-harmless$ C.-Y. Hsu, C.-M. Yu, C.-Y. Huang, J. Sakuma. Harmless Yet Harmful: Neutral Prompting Attacks for Stealthy Hallucination Steering in Agent Skills. 2026. arXiv:2605.29354.

$Rn-steer$ Y. Liu, C.-Y. Hsu, C.-Y. Huang, M. Backes, R. Wen, C.-M. Yu. Trust Me, Import This: Dependency Steering Attacks via Malicious Agent Skills. 2026. arXiv:2605.09594.

$Rn-cloak$ Z. Ji, C. Xu, Z. Li, Y. Gao, X. Wei, S. Wang, S.-C. Cheung. Cloak and Detonate: Scanner Evasion and Dynamic Detection of Agent Skill Malware. 2026. arXiv:2607.02357.

$Rn-greshake$ E. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, M. Fritz. Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. 2023. arXiv:2302.12173.

$Rn-iqbal$ U. Iqbal, T. Kohno, F. Roesner. LLM Platform Security: Applying a Systematic Evaluation Framework to OpenAI's ChatGPT Plugins. AAAI/ACM AIES 2024. arXiv:2309.10254.

$Rn-mcpsec$ S. J. Gan, et al. Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions. 2025. arXiv:2503.23278.

$Rn-mcpserver$ M. Hasan, et al. MCP at First Glance: Studying the Security and Maintainability of MCP Servers. 2025. arXiv:2506.13538.

$Rn-mcpparasitic$ Mind Your Server: A Systematic Study of Parasitic Toolchain Attacks on the MCP Ecosystem. IEEE S&P 2026. arXiv:2509.06572.

$Rn-halluc-pkg$ We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. 2024. arXiv:2406.10279.

$Rn-halluc-import$ K. Krishna, et al. Importing Phantoms: Measuring LLM Package Hallucination Vulnerabilities. 2025. arXiv:2501.19012.

$Rn-halluc$ A. Churilov. The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort. 2026. arXiv:2605.17062.

$Rn-slop$ S. Baltes, et al. "An Endless Stream of AI Slop": The Growing Burden of AI-Assisted Software Development. 2026. arXiv:2603.27249.

$Rn-aihw$ Human-Written vs. AI-Generated Code: A Large-Scale Study of Defects, Vulnerabilities, and Complexity. 2025. arXiv:2508.21634.

$Rn-crowd$ Measuring and Understanding Crowdturfing in the App Store. Information 14(7):393, 2023.

$Rn-fakex$ FakeX: A Framework for Detecting Fake Reviews of Browser Extensions. ASIACCS 2024. DOI: 10.1145/3634737.3656999.

$Rn-atlas$ MITRE ATLAS. Poisoned Postmark MCP Server Email Exfiltration（AML-CS0053）. 2025.

$Rn-cws$ Chrome Web Store 恶意扩展实证研究（更新管道攻破：16+ 扩展、320 万+ 用户受影响；2023--2026，具体条目见 reference_papers/evolution3-references.md）。

$Rn-vscode$ VS Code 扩展安全研究（Verified 徽章绕过 / 发布者身份锚定不足；2023--2025，具体条目见 reference_papers/evolution3-references.md）。

$Rn-gov$ 平台治理与信誉系统研究（App Store 审核 / 评分操纵 / AI 垃圾内容；2023--2026，含 $Rn-crowd$ $Rn-fakex$ ，更多条目见 reference_papers/evolution3-references.md）。

$Rn-ek$ G. Akerlof. The Market for "Lemons": Quality Uncertainty and the Market Mechanism. QJE 84(3):488--500, 1970.

$Rn-eco$ S. Jansen. Software Ecosystems Governance: A Systematic Literature Review and Research Agenda. 2017. DOI: 10.5220/0006269402150226.

$R2$ DeepSeek AI. DeepSeek Harness（开源仓库与文档）. https://github.com/deepseek-ai/DeepSeek-Harness

$R4$ S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, Y. Cao. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arXiv:2210.03629.

$R5$ T. Schick, J. Dwivedi-Yu, R. Dessì, et al. Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023. arXiv:2302.04761.

$Rn-awesome$ awesome-dsh-plugin（社区插件精选列表，生态现状数据源）. https://github.com/deepseek-ai/awesome-dsh-plugin

【DeepSeek Harness 研究】进化方向3：插件生态治理 思考、设计与实现

deepseek harness 进化方向3：插件生态治理 思考、设计与实现