插件别急着装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 --repogithub.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 插件盖上“绝对安全”的章。真正可靠的流程永远是先固定来源再自动扫描先人工读配置再隔离试跑最后才进入真实工作区。插件越强这套顺序越不能省。
插件别急着装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 --repogithub.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 插件盖上“绝对安全”的章。真正可靠的流程永远是先固定来源再自动扫描先人工读配置再隔离试跑最后才进入真实工作区。插件越强这套顺序越不能省。
