7 篇博文 含有标签「supply-chain」

你的 CI 流水线固若金汤。容器镜像在部署前经过签名和验证。每个 npm 和 PyPI 依赖项都根据带有固定哈希值的锁文件进行解析。提交需要签名标签。然后，在你模型服务启动脚本的某个地方，有一行代码从模型中心或 S3 存储桶下载数 GB 的二进制大对象（blob）并将其加载到内存中——没有签名检查，没有哈希验证，也没有生产者的记录。这个对你产品实际功能起决定性作用的唯一制品，偏偏是你的供应链工具从未听说过的那个。

这并非虚构的漏洞。安全研究人员已经从公共中心撤下了数百个恶意模型——这些模型在你加载它们的瞬间就会执行攻击者代码，它们是专为绕过中心运行的扫描器而精心设计的。弥补这一漏洞的工具现已存在：安全序列化格式、行业签名规范、以及拒绝未签名权重的准入控制器。大多数团队只是还没意识到，“模型文件”与“来自互联网且未经审计的二进制文件”在本质上是同一类东西。

每个安全团队对拼写抢注 (typosquatting) 都有一个心智模型：攻击者注册 requets 并等待有人误输入 requests。这行得通，但它是对人类粗心大意的一种随机押注。Slopsquatting 则更糟糕，因为这种“拼写错误”并非随机。语言模型会以可预测、可重复的模式虚构出看似合理但并不存在的包名——攻击者可以查询你使用的相同模型，收集它们虚构的名字，并准确地在 PyPI 和 npm 上注册这些包。幻觉变成了预购单。你的编码智能体 (coding agent) 在拥有自主安装权限的情况下运行，就是那个取走包裹的顾客。

这并非假设。关于这一现象的最大规模研究对 16 个模型生成了 223 万个代码样本，发现 19.7% 的推荐包并不存在——涉及 205,474 个独特的虚构名称。当一位安全研究员将其中一个最常被幻觉出的 Python 包注册为一个无害的空壳时，它在三个月内被下载了超过 30,000 次，并最终出现在一家大型科技公司开源仓库的安装说明中。由“氛围编程” (vibe coding) 带来的供应链攻击已经完成了它的概念验证。

在任何严肃的微调项目进入到第九个月时，你的训练语料库的作者数量可能已经超过了你的代码库。合成生成流水线编写了数百万个示例。供应商标注公司从你从未见过的劳动力那里贡献了 8 万行数据。一位工程师在上周二添加了 47 个示例，以修复他们在评估（eval）中发现的回归问题。一个抓取任务每天晚上将生产环境的追踪记录（traces）拉取到一个“补充”的 parquet 文件中。二月份有人扔进 S3 的一个 CSV 文件仍然在那里，仍然处于训练组合中，而编写该文件的人已经在三月份离职了。

现在看看你的应用程序代码仓库。每一行代码都可以追溯到具体的作者。每一次变更都经过了至少一名审核者的 PR。提交（Commits）是经过签名的。主分支（Main branch）是受保护的。合并需要第二个人参与。这里有审计日志。如果审计员询问 payment_processor.py 的第 47 行是谁写的，你可以在几秒钟内给出答案。

如果他们问产生模型 v2.3 的语料库中的第 47 个示例是谁写的，诚实的回答是“2024 年第二季度的 Mechanical Turk 批次，供应商未知，理由缺失。”你的微调语料库是比代码库权限更高的部署表面——它直接决定了生产环境中模型的行为——而你正在通过存储桶（bucket）发布它，却通过经过审查的 PR 发布代码。威胁模型被倒置了。

在 “开放权重”（open-weight）这个词中，“开放” 二字承担了极大的重任。当一名工程师从模型中心下载 safetensors 文件时，他们往往倾向于将这种行为归类为与 npm install lodash 相同的心理范畴 —— 拉取依赖、上线功能、继续下一步。但伴随这些权重而来的许可证很少是 Apache 2.0 或 MIT。它通常是带有可接受使用例外项、署名要求、衍生品命名规则以及用户数量阈值的自定义社区许可证，一旦你的产品变得流行，这些阈值就会改变合同条款。而且，加载器几乎不会强制执行其中任何一项。无论你是否遵守，模型都会运行。

这就是合规债务如何悄无声息地累积的。如果团队将许可证审查视为一次性的下载检查，那么公司就在为一项审计结果埋单，而该结果将在点击 “我同意” 的开发者离职多年后才会显现。解决方法不是在入口处设置更严格的采购门槛，而是将模型权重视为供应链的一种严谨做法，具备来源追溯、定期重新审查以及一份能够将每条已部署的推理路径追溯回其上游许可证的清单。

你的 Agent 每五分钟调用一次的 MCP 服务，其最后一次 commit 还是在八个月前。它所封装的上游 API 在二月份推出了新的身份验证模型。目前有 47 个未解决的 issue，其中 12 个被标记为安全风险。维护者的 GitHub 账号自十月以来就没有过任何活动。你的 Agent 仍然能够连接，仍然能够接收工具描述，仍然能够执行调用 —— 而在无声无息中，每一次调用都流经一段无人看管的基础设施。

这就是 MCP 被遗弃的现状。不是恶意的卷款跑路（rug pull），也不是被攻破的软件包，仅仅是由于疏忽。有人在 2025 年发布了一个有用的服务，被大家采用后，便转向了其他项目。该服务之所以能继续运行，是因为没有任何因素强行让它崩溃。直到它彻底崩溃 —— 而到那时，你的 Agent 每五分钟跨越一次的信任边界其实早已失效。

大多数团队采用社区 MCP 服务的方式与采用 npm 包的方式如出一辙：运行 install 并阅读 README。这种思维模型在面对 MCP 时失效了。在 MCP 中，依赖是一个动态的信任边界，LLM 在循环中携带凭据，并在生产数据上对其进行调用。

MCP 生态已拥有 10,000+ 服务器和 9700 万次 SDK 下载量。但同时也在六十天内出现了 30 个 CVE、502 个未锁定版本的服务器配置，以及一个在十五个版本中悄悄将每封外发邮件密送给攻击者的供应链攻击。可组合性的承诺——「只需再接入一个 MCP 服务器」——是真实的。但它带来的依赖蔓延也是真实的，大多数团队在深陷集成债务之后才发现其代价。

如果你在 npm 上构建过生产系统，你一定看过这部电影。MCP 生态正在加速重演同一剧情，只不过这次的「包」拥有对你机器的 shell 访问权限和生产系统的凭证。

2025 年 9 月，一个每周下载量达 1,500 次的非官方 Postmark MCP 服务端被悄悄篡改了。更新在其 send_email 函数中添加了一个单一的 BCC 字段，静默地将每封邮件抄送给攻击者的地址。启用了自动更新的用户开始在没有任何可见行为变化的情况下泄露邮件内容。没有错误。没有警报。该工具的工作表现完全符合预期 —— 只是它也在为别人工作。

这是供应链攻击的新形态。不是受损的二进制文件或被植入木马的库，而是 AI 智能体盲目信任的被投毒的工具定义。随着注册中心索引了超过 12,000 个公共 MCP 服务端，且该协议正成为 AI 智能体的默认集成层，MCP 生态系统正在重现 npm 生态系统犯过的每一个错误 —— 只是现在的波及范围包括了你的智能体代表你阅读文件、发送消息和执行代码的能力。