MCP Server 供应链安全：从 npx -y 的隐患到可落地的防御清单

一、上一篇埋的坑：server 本身可信吗

《MCP 安全实战》那篇讲的是"工具怎么被滥用"，这篇补上另一半：你运行的这个 MCP server，本身是从谁手里、以什么版本、经过什么构建流程到你机器上的？ 工具描述再干净，server 二进制被掉了包，一切防御都是空中楼阁。

先看一个几乎所有人都在写的配置：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

npx -y 的语义是：本地没有这个包就静默安装，有就用本地的。它隐含了三个风险：版本浮动（今天装的是 1.0.0，明天新机器装的可能就是 1.0.3）；安装即执行（npm 包的 postinstall 脚本会随安装运行）；来源即信任（npm 上的 @modelcontextprotocol scope 真的是官方的吗？scope 被转让、账号被劫持的历史案例并不少）。

二、三类真实攻击面

2.1 依赖投毒：typosquatting 与 install script

攻击者注册一个与热门包相差一个字母的名字，或者给包挂上恶意 postinstall：

// 恶意包 package.json 的关键字段
{
  "name": "@modelcontextprotocl/server-github",  // 少个 e
  "scripts": { "postinstall": "node ./scripts/check-update.js" }
}

MCP 生态放大了这类攻击的效果：server 一旦运行，天然持有模型上下文的读写权和用户授予的工具权限。

2.2 构建与分发劫持

GitHub repo 干净 ≠ npm 包干净。发布流水线被入侵（维护者 token 泄露）、构建机被植入、发布时混入不同代码，都是真实发生过的场景。对 MCP server 这种"拿到了就要跑"的软件，分发环节的任何缺口都直通用户机器。

2.3 版本浮动与锁文件缺失

团队里五个人装同一个 server，五台机器上跑着五个版本，其中一个版本的依赖树里混进了被投毒的传递依赖——排查时你甚至不知道该对比什么。

三、可落地的六层防御

第一层：锁版本，拒绝浮动

把 MCP server 当生产依赖管理，而不是当脚本随手跑：

# 项目内固定版本安装，不用 npx -y
npm install @modelcontextprotocol/server-github@1.0.0 --save-exact
# 提交 package-lock.json，CI 里用 npm ci 保证可复现
npm ci

{
  "mcpServers": {
    "github": {
      "command": "node",
      "args": ["./node_modules/@modelcontextprotocol/server-github/dist/index.js"]
    }
  }
}

第二层：审计安装脚本

安装前先看它要执行什么：

# 查看 postinstall 等生命周期脚本
npm view @modelcontextprotocol/server-github scripts
# 全局禁止 install script，按需白名单
npm config set ignore-scripts true

ignore-scripts=true 应该成为团队默认配置，需要脚本的包单独豁免并人工 review。

第三层：依赖情报与最小依赖树

npm audit 只覆盖已知漏洞，对新增恶意包要靠情报工具（如 socket.dev 的安装时分析）。同时控制依赖树体积：一个天气查询 server 依赖 300 个传递包，攻击面就是 300 个。

第四层：私有 registry 代理

企业内网搭 npm 代理（如 verdaccio / 制品库），白名单放行经过审查的包，MCP server 的安装流量全部走代理。这一层把"谁来决定哪些包可信"从个人习惯变成组织流程。

第五层：容器化 + 最小权限运行

沿用上一篇的沙箱思路，server 进程容器化：只读根文件系统、独立网络命名空间、出网白名单、非 root 运行。即使供应链被击穿，爆炸半径也被限制在容器内。

FROM node:20-alpine
RUN addgroup -S mcp && adduser -S mcp -G mcp
WORKDIR /app
COPY package-lock.json package.json ./
RUN npm ci --omit=dev && chown -R mcp:mcp /app
USER mcp
CMD ["node", "node_modules/@modelcontextprotocol/server-github/dist/index.js"]

第六层：验证发布来源

优先选择有 provenance 签名的包（npm 9.5+ 支持 provenance，可验证包由声明的 repo 与 CI 构建）；关注官方仓库的 Release 与 npm 版本是否一致；对关键 server 可以自己从源码构建镜像，彻底绕过 npm 分发。

四、检查清单

1. 不用 npx -y 跑生产 server，版本锁死 + lockfile 入库
2. ignore-scripts 默认开启，生命周期脚本单独豁免
3. 安装前查包：scripts、依赖数、发布时间、维护者历史
4. 企业内走私有 registry 白名单
5. server 容器化 + 非 root + 出网白名单
6. 关键 server 优先 provenance 签名或源码自构建
7. 版本升级视同变更管理：走上一篇的工具指纹基线流程

五、写在最后

把两篇连起来看，MCP 安全的完整拼图是：server 从哪来（本篇）→ 工具描述说了什么（上一篇）→ 参数去了哪里（出网管控）→ 出事怎么查（审计）。供应链这一层没有高深的对抗，全是工程纪律——而工程纪律恰恰是最难坚持的防线。

系列下一篇计划聊 MCP 的权限模型：工具粒度的授权、确认 UI 的信息设计，以及多 server 场景下的权限隔离。