跳到主要内容

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

查看所有标签

你的微调语料库是代码库。别再通过存储桶交付了。

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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

开放权重模型许可是你的团队尚未规划的合规雷区

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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

MCP 服务端坟场:当你的智能体依赖停止更新时

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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

MCP 可组合性陷阱:当「再加一个服务器」变成依赖地狱

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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

MCP 服务端供应链风险:当你的智能体工具成为攻击向量

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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