dsh.so 如何验证插件

dsh.so 是面向 DeepSeek Harness 插件的独立信任与发现市场。本页说明一个对象从被发现到被验证的完整路径、我们的自动化能告诉你什么、不能告诉你什么，以及当前管线止步于何处。

六阶段管线

信任模型：三个不等式

这三句话是承重墙。本页其余内容都应在它们的背景下阅读。

我们验证什么

• 一个对象能解析到唯一可达的 GitHub 仓库。
• 用户安装前需要的元数据存在且自洽。
• 插件代码与依赖中的可观察模式，经由沙盒扫描获得。
• 这些模式背后的上下文，经由模型驱动的动态安全审计获得——它读脱敏后的源码快照，只覆盖「静态判定在 warn 及以上」的子集，不执行插件代码，结论只升不豁免。
• 维护新鲜度，以绝对快照表达——绝不以增长表述。

我们不验证什么

• 不存在恶意行为。自动化验证无法担保插件当下或未来任何一次更新后不含恶意逻辑。
• 作者意图。安全发现描述的是一个可观察模式，不是作者的心理状态。
• 每条运行路径的运行时安全。沙盒扫描是对行为的抽样，无法穷举插件在你机器上可能做的一切。动态安全审计读的是脱敏后的源码快照、同样不运行插件，因此也观察不到任何运行时行为。
• 全库的动态覆盖。动态审计队列只收录静态判定在 warn 及以上的插件，且只看管线实际采集到的源码。不在队列里，就意味着它没有被动态审计过；而审计「无结论」也不等于「通过」。
• 背书。dsh.so 上的任何内容都不是推荐。Verified 意味着测过，不意味着可信。

局限

自动化验证无法担保不存在恶意行为。扫描是时间点快照：今天通过的插件明天就可能变化，插件市场按自己的节奏重扫而非持续盯防。启发式扫描器会产生误报——critical 档是「去看一眼」的指令，不是判决书；而对我们而言全新的模式也可能漏报（假阴性）。最后，索引本身有边界：不在我们发现面之内的插件在这里不可见，这就是站内每个数字都要标注口径的原因。动态安全审计在此之上还有第二重边界：它只覆盖管线实际采集到的源码，且只针对静态判定已在 warn 及以上的插件——所以它的覆盖是静态扫描的子集，不是全库。

误报与更正

如果你的插件带着一条你认为错误的发现，请携带发现标识符到插件市场仓库提 issue。确认的误报会在下一轮扫描周期修正，每日快照会记录更正历史而不是覆盖它。

更新频率

插件市场数据按小时级流水线刷新（发现、投稿、安全报告）。每天 03:17 UTC 的快照把六个口径指标冻结进追加式历史文件；本站发布的每个数字都注明它来自哪一天的快照。

数据来源

• GitHub API——仓库元数据、topic、star、提交活动。
• npm registry——包存在性、周下载量、仓库交叉核对。
• L4 沙盒扫描——逐插件发现分档。
• 模型驱动的动态安全审计——在有界范围内采集脱敏后的源码快照做上下文审计，从不执行插件代码；队列只收录静态判定在 warn 及以上的插件。
• 手动投稿——进入索引前经人工审核。