插件别急着装：3 个 GitHub 开源工具给 DeepSeek Harness 做安装前体检
上一期讲了 DeepSeek Harness 插件的风险。
最危险的地方不在“插件能不能用”，而在它可能同时进入安装脚本、配置层、Host 运行时、工具链和模型上下文。
问题来了：
普通用户不可能逐行看懂整个仓库，安装前到底怎么审？
答案不是找一个“安全检测”按钮，然后看到绿色就直接放行。
更稳的办法，是用三类工具分别看三层风险：
Cisco Skill Scanner：检查 AI 特有的指令与恶意行为模式；
OpenSSF Scorecard：检查 GitHub 仓库的供应链健康；
Google OSV-Scanner：检查依赖中已经公开的漏洞。
最后再补一轮 DSH 专项人工检查。
这四层拼起来，才算一次完整的安装前体检。
第一层：Skill Scanner 查“这个插件想做什么”
Cisco 在 GitHub 开源的 Skill Scanner，原本面向 Agent Skills。
它会检查提示词注入、数据外传、恶意命令链、混淆内容、可疑二进制和 Python 字节码等风险，也能选配行为数据流与 LLM 语义分析。
截至 8 月 21 日，这个仓库已经获得约 2.4k Stars，最新 Release 是 2.0.13。
它最适合解决传统依赖扫描器看不到的问题：
一段文字是否在诱导 Agent 忽略规则？
某个脚本是否把敏感文件送进网络请求？
Shell 管道是否把外部输入直接拼进命令？
仓库里是否混入了没有源码对应的字节码或可疑文件？
如果扫描器已经在隔离环境中按固定版本准备好，可以先对 GitHub 仓库执行：
skill-scanner scan-repo owner/repo --lenient --skill-file README.md --policy strict --format html --output skill-report.html这条命令的几个关键点：
scan-repo：直接读取待审 GitHub 仓库；--lenient：允许非标准 Skill 目录继续进入扫描；--skill-file README.md：把普通插件 README 作为描述入口；--policy strict：使用严格策略；--format html：生成更适合人工阅读的报告。
但必须说清楚：
DSH 插件通常是 TypeScript 工程，不是标准 Agent Skill。
Skill Scanner 能检查很多通用文件、命令链和文本风险，但它的行为数据流分析主要面向 Python，不能当成完整的 TypeScript 代码审计。
所以它是第一道筛网，不是最终裁判。
第二层：Scorecard 查“这个仓库靠不靠谱”
恶意代码不是唯一风险。
一个插件仓库如果长期无人维护、主分支可以随意强推、发布包没有签名、工作流权限过大、依赖不固定，也可能在未来变成供应链入口。
OpenSSF Scorecard 会检查：
项目是否仍在维护；
是否启用分支保护；
代码是否经过评审；
GitHub Actions 是否存在危险写法；
工作流 Token 权限是否过大；
依赖是否固定；
仓库是否包含不透明二进制；
Release 是否带签名或来源证明。
工具准备完成后，可以针对仓库运行：
scorecard --repo=github.com/owner/repo这里不要只盯总分。
对插件来说，更值得看的是单项：
Dangerous-Workflow、Token-Permissions、Binary-Artifacts、Pinned-Dependencies、Code-Review和Signed-Releases。
低分不等于仓库一定恶意，高分也不代表每一行代码都安全。
Scorecard 回答的是“这个项目的供应链管理是否健康”，不是“这段插件代码会不会偷数据”。
第三层：OSV-Scanner 查“依赖有没有已知漏洞”
一个插件本身只有几百行代码，依赖却可能有几百个包。
这些依赖里只要有一个已知高危漏洞，就可能把风险带进 DSH 的 Host 进程。
Google 的 OSV-Scanner 会读取package.json和锁文件，把精确依赖版本与 OSV 漏洞数据库进行匹配。
对已经安全下载到隔离目录、但尚未安装和构建的插件，可以运行：
osv-scanner scan source -r ./plugin-review它支持 npm、pnpm、yarn 和 bun 等 JavaScript 锁文件。
这里同样有边界：
OSV-Scanner 擅长发现“已经公开、已经进入数据库”的依赖漏洞。
它看不懂恶意业务逻辑，也无法发现尚未公开的零日漏洞，更不会替你判断prepare脚本为什么要联网。
另外，默认在线扫描会向漏洞服务发送包名、版本、生态和部分哈希，不会发送源代码；敏感环境仍应根据需要使用离线模式。
第四层：三个文件必须人工看
前三层都跑完，还不能直接安装。
DSH 插件有三个特别关键的检查点，通用工具无法替你做最终判断。
第一个是package.json。
重点看preinstall、install、postinstall、prepare，以及依赖里是否出现陌生 Git 地址、本地压缩包和原生二进制。
第二个是dsh.bundle。
它会告诉你，这个 npm 包准备向 DSH 注入哪一层配置。
第三个是cordis.patch.yml。
逐项确认它新增或覆盖的插件 ID，特别关注沙箱、审批、Shell、文件、网络、模型提供商和凭据相关配置。
如果这三处解释不清，扫描报告再漂亮也不要安装。
报告出来以后，怎样做决定？
可以用一套很简单的红黄绿规则。
红色，直接停止：
发现凭据搜集、浏览器或钱包读取；
出现混淆下载器、远程脚本、静默外传；
要求关闭安全软件、提权或开放整个磁盘；
高危命令链无法解释；
源码和二进制无法对应。
黄色，暂停人工复核：
存在安装生命周期脚本；
Scorecard 某些关键项很低；
依赖包含高危漏洞但有可用修复版本；
插件覆盖已有 DSH 配置；
需要访问外部 API 或敏感目录。
绿色，只代表可以进入隔离试跑：
三类扫描未发现高危信号；
安装脚本和配置覆盖已经人工解释；
版本固定到完整 Commit；
首次运行不带 Token、账号和私人文件；
使用最小权限与独立工作区。
注意，绿色不是“确认安全”。
它只代表目前有足够证据，可以进入下一道验证。
还有一个很容易踩的隐私坑
Skill Scanner 支持 VirusTotal 和云端语义分析，但这些都是可选能力。
如果开启“上传未知文件”，本地文件可能被送往第三方服务。
私有插件、公司代码、未公开素材和任何含凭据的文件，都不能在没有明确授权时上传。
对普通用户，更稳的顺序是：
先跑本地静态、字节码和命令链分析；
确有必要时，再使用不上传文件的哈希查询或经过批准的云分析。
最后一句
Skill Scanner 像一支检查 AI 指令的手电筒；
Scorecard 像仓库供应链的体检表；
OSV-Scanner 像依赖漏洞的黑名单对照器。
三者都很有用，但没有一个能给 DSH 插件盖上“绝对安全”的章。
真正可靠的流程永远是：
先固定来源，再自动扫描；先人工读配置，再隔离试跑；最后才进入真实工作区。
插件越强，这套顺序越不能省。
