4.2 Skill 与 MCP 来源锁定与审查流程
4.2 Skill 与 MCP 来源锁定与审查流程
本节摘要：4.1 节的四步自查解决「这一个能不能装」，本节解决「整个进料口怎么运转」。四块内容：其一，来源分级——官方、组织内部、知名社区、陌生来源四级，各级走不同准入通道，信任不是给个体的，是给类别的；其二，版本锁定——一份 manifest 锁定文件（skills.lock）把每个已入库 Skill / MCP 的名称、版本、来源与逐文件哈希钉死，配一个 lock_verify.py 校验器，安装树与锁定文件不一致即报警；其三，入库审查流水线——提交、自动化检查、沙箱试跑、人工预览、锁定入库五站，人工预览站回执必须完整展示将执行的内容，这正是 CVE-2026-100602 教训的制度化；其四，更新差异审查——更新按 diff 审而不是按重装审，diff 基准就是锁定文件，校验器进 CI 当卡点。至此供应链治理与第 3 章的审批门、审计正式咬合。
学习目标
- 用来源分级表决定每个外来件走哪条准入通道。
- 写出覆盖 Skill 与 MCP 的 manifest 锁定文件并用校验器验证。
- 描述入库审查流水线五站的判据与出口，说清人工预览站为何不可裁剪。
- 把更新差异审查接入 CI，形成可执行的卡点。
一、来源分级：不是所有来源都值得同样的信任
逐件深审的成本撑不住，出路是按来源分级——同级别共享同一条通道，通道内再用抽查兜底。四级划分（本书建议，可按组织情况裁剪）：
| 级别 | 定义 | 准入通道 | 抽检要求 |
|---|---|---|---|
| A · 官方 | Agent 平台或 Skill 官方发布渠道 | 快速通道：清单比对 + 哈希锁定 | 每季度抽检一次 |
| B · 组织内部 | 自己团队沉淀、有明确维护人 | 同事评审 + 锁定 | 随版本评审 |
| C · 知名社区 | 有维护历史与使用者规模的社区项目 | 全流程：四步自查 + 流水线 | 每次更新必审 |
| D · 陌生来源 | 新账户、无历史、无可考使用者 | 默认拒绝；确需使用走沙箱试跑 + 双人审批 | 不适用（每件全审） |
分级的本质是把有限的人审注意力投向边际收益最高的地方：D 级全拦、C 级全审、A 与 B 级靠锁定与抽检维持。注意分级对象是来源类别，不因某个 Skill 星标多、名字熟就单独提级——口碑不是审计。
二、版本锁定：manifest 锁定文件
锁定的目标：进料口的每一个件，其身份（名称、版本、来源）与内容（逐文件哈希）在任何时刻都可回答「装的是不是审过的那个」。锁定文件 skills.lock.json 的结构示意：
{ "schema": "1", "generated_at": "2026-09-29T00:00:00+00:00", "skills": [ { "name": "skill-xyz", "version": "1.0.2", "source": "official-registry", "grade": "A", "files": { "SKILL.md": "sha256:3f9a…", "scripts/run.py": "sha256:8c21…" } } ], "mcp_servers": [ { "name": "db-query", "version": "0.4.1", "source": "internal-git", "grade": "B", "command_digest": "sha256:d0e7…", "env_allowlist": ["DB_NAME", "DB_READONLY"], "files": {"server.py": "sha256:1b44…"} } ] }
两个设计点：files 存逐文件哈希而不是整目录一个哈希——更新审查时能精确说出哪个文件变了；MCP 条目带 env_allowlist——环境变量是第 5.2 节要讲的常见泄露面，进料口就把它收进白名单。配套校验器：
# lock_verify.py —— 校验已安装内容与锁定文件一致（示意实现） import hashlib, json, os, sys def tree_digest(root: str) -> dict: digests = {} for base, _, files in os.walk(root): for name in sorted(files): path = os.path.join(base, name) rel = os.path.relpath(path, root).replace("\\", "/") digests[rel] = "sha256:" + hashlib.sha256(open(path, "rb").read()).hexdigest() return digests def main(lock_path: str, skills_dir: str) -> int: lock = json.load(open(lock_path, encoding="utf-8")) bad = 0 for item in lock["skills"]: actual = tree_digest(os.path.join(skills_dir, item["name"])) if actual != item["files"]: print(f"[不一致] {item['name']}：版本漂移或内容被改") bad += 1 else: print(f"[一致] {item['name']}@{item['version']}") return 1 if bad else 0 if __name__ == "__main__": sys.exit(main("skills.lock.json", "./skills"))
运行 python lock_verify.py skills.lock.json ./skills，退出码非零即有不一致。锁定纪律只有三条：安装与升级必须改锁定文件；锁定文件的变更走代码评审；沙箱运行环境定期跑校验器，防「审的时候是一个样、跑的时候另一个样」——MCP 常驻进程的版本漂移就死在这一步。
三、入库审查流水线：五站式
入库审查流水线（每站都有放行与退回两个出口） 提交申请 ──▶ ① 自动化检查 ──▶ ② 沙箱试跑 ──▶ ③ 人工预览 ──▶ ④ 锁定入库 ──▶ ⑤ 分发 (名称/版本/ (清单比对、读取 (断网沙箱干跑、 (回执完整展示 (写入 lock、 (按工作区 来源/用途) 检索、哈希计算) 审计时间线回看) 行为与 diff) 存档 diff) 按需装) │ │ │ │ └── 信息不全退回 ┘── 红旗命中拒绝 ┘── 越界记录退回 ┘── 人拒绝即终止（全部留审计）
各站判据：第一站查材料的完整性；第二站自动跑 4.1 节的安装与读取检查并计算哈希；第三站用 sandbox_run.py 干跑（对应 4.1 第三步）；第四站是人工预览——回执必须完整展示将执行的内容与全部差异，审批人签字才放行。第四站不可裁剪、不可合并：CVE-2026-100602 的官方记录指向的正是「预览」环节缺失，批准动作与实际内容脱节。第 3.1 节说过审批门的两个人的因素——回执带完整命令、重复审批合并提示——流水线把它们一并继承。
💡 流水线与第 3 章的分工：审批门（3.1）管的是运行期单条命令的灰区决策，入库审查管的是进料期整个件的准入。前者高频、轻量、可合并；后者低频、重量、必存档。两道门都开着，供应链与执行侧才闭环。
四、更新差异审查：更新是重审，不是续费
绝大多数供应链事件发生在「更新」而不是「首次安装」——首次安装人人警惕，更新常常默认信任。更新审查的流程：
- 取新版本，重算文件清单与哈希；
- 与锁定文件里的基准做逐文件 diff（对应 4.1 第四步）；
- 人读 diff：变更是否与该版本的变更说明吻合；
- 通过则更新锁定文件并归档 diff，未通过按新申请退回。
三条红线（diff 中出现即升级为全新审查，重走流水线）：新增可执行文件或脚本入口；新增网络、环境变量、敏感路径引用；变更说明解释不了的任何改动。再配两个机制把流程钉住：lock_verify.py 进 CI——实际安装与锁定文件不一致就红；安全更新走快速通道——「不更新也有风险」，为官方安全通告留出加急评审位，避免流程把人逼向「干脆不更新」。
⚠️ 规模提醒：「824 个恶意 Skill 遍布 5 个市场」为单一来源数字，仅供参考；但即便只采信官方 CVE 这一条确证事实，结论也不变——市场存在恶意供给，进料口必须有制度。制度的强度不必一步到位：从「一份锁定文件加一个校验器」起步，就足以让多数漂移与篡改无处藏身。
本节要点回顾
- 来源分级四级四通道：D 默认拒绝、C 全流程、A 与 B 靠锁定加抽检；信任给类别不给个体。
- skills.lock.json 钉死名称、版本、来源与逐文件哈希；lock_verify.py 退出码即判据；三条锁定纪律。
- 入库流水线五站，人工预览站不可裁剪——CVE-2026-100602 教训的制度化；与第 3 章审批门分工明确。
- 更新按 diff 审，基准是锁定文件；三条红线；校验器进 CI，安全更新留快速通道。
进料口有了制度，但制度挡不住全部——混淆得当的载荷可能通过审查，受信任的件也可能在运行后才暴露异常。下一章把镜头转向运行时：盯行为而不盯出身，用四类信号与滑动窗口熔断兜住漏网者；并回答一个更硬的问题——如果真逃逸了，怎么把损害压到最小。