为权重签名：模型是供应链忽略的可执行文件

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

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

原罪：加载即执行的格式

模型文件之所以比 JPEG 更值得怀疑，归根结底在于序列化的历史。PyTorch 的默认保存格式建立在 Python 的 pickle 之上，而 pickle 并不是一种数据格式——它是针对虚拟机的一个微型指令流，可以在反序列化期间调用任意 Python 可调用对象。加载 pickle 文件就是在运行别人编写的程序。多年以来，在下载的检查点（checkpoint）上执行 torch.load() 正是这个意思。

攻击者早在大多数机器学习团队之前就意识到了这一点。2024 年初，JFrog 的研究人员在 Hugging Face 上发现了 100 多个能在加载时执行代码的模型，其中一个甚至打开了指向攻击者控制主机的反向 shell——这是一个伪装成“预训练模型”的无声后门。一年后，ReversingLabs 记录了他们称之为 nullifAI 的技术：恶意 pickle 负载被压缩成 7z 格式而非预期的 ZIP 格式，这破坏了中心（hub）的 PickleScan 检测，但仍能被一些过于“热心”的消费者工具加载。Protect AI 在扫描数百万个中心制品时，标记了数万个模型中的数十万个不安全或可疑问题。

这场扫描军备竞赛对扫描器来说结果并不理想。到 2025 年，JFrog 和 Sonatype 仅在 PickleScan 中就披露了 7 个不同的绕过漏洞——包括扫描器拒绝但加载器接受的损坏 pickle 流、归档标记操纵、以及逃避黑名单的子类技巧。任何目睹过 2000 年代杀毒软件败给恶意软件加壳工具的人，都会觉得这种模式非常熟悉。对图灵完备格式进行基于黑名单的扫描，是在原地踏步，而不是防御。

结构性的解决方案是彻底停止使用可执行格式。Safetensors（现隶属于 PyTorch 基金会）将张量存储为带有 JSON 标头的纯数据：没有操作码，没有可调用对象，没有任何可执行内容。ONNX 和 GGUF 同样是惰性的。“仅限 safetensors”的策略将代码执行风险转变为单纯的数据完整性风险。这是真正的进步，但请注意它无法解决的问题：攻击者虽然无法在加载时执行代码，但如果他们能写入你的模型存储桶，他们仍然可以换掉权重，让模型表现异常。这把我们带到了没有人进行过威胁建模的部分。

被篡改的权重比被篡改的代码更糟糕

这就是令人不安的不对称性。如果攻击者修改了你的应用程序二进制文件，你拥有数十年积累的工具来察觉：可重现构建、二进制差异对比、EDR、以及每次更改的代码审查。如果攻击者修改了你的模型权重，到底有什么能捕捉到它？该文件是数十亿个不透明的浮点数。张量没有代码审查。一个插入了针对性后门的微调模型——除了包含触发词的输入外，对其他所有输入都响应正常——对你运行的任何评估（eval）都是不可见的，因为你根本不知道该评估什么。

审视实际的攻击面：

• 具有宽泛写入权限的注册中心存储桶。 大多数公司将微调后的权重存储在对象存储中。审计谁拥有该存储桶的写入权限，你通常会发现答案是“每位数据科学家、几个 CI 服务账户，以及一个以管理员凭据运行的训练作业”。任何一个凭据泄露都意味着静默的权重替换。
• 被投毒的上游检查点。 你基于从中心拉取的基础模型进行微调。命名空间抢注、仿冒组织名称和被劫持的维护者账户都被用于提供被投毒的检查点。你的微调继承了基础模型包含的所有内容，而你的溯源轨迹从一开始就是一个谎言。
• 被入侵的训练流水线。 训练作业会拉取数十个 Python 依赖项。一个恶意的传递依赖项不需要攻击你的基础设施——它只需在辅助生产权重时稍作改动，同时保持训练损失曲线看起来完全正常。
• 内部重新托管。 团队“为了可靠性”将外部模型镜像到内部注册中心，通常使用的是不验证任何内容的复制脚本。镜像变成了一个无法审计的分支：没人能说清内部副本是否仍与上游匹配，因为没人记录上游的字节数据是什么。

共同点在于：在任何情况下，你都无法回答这个问题——“我们提供的字节流是我们预期提供的吗？是谁生产了它们？”这不是一个机器学习问题。这正是软件供应链安全在过去十年中致力于构建机制来回答的问题——签名、溯源认证、透明度日志。只是这些机制从未对准过模型文件。

新兴学科：OMS、Sigstore 与签名权重

这种情况正在改变。2025 年 4 月，OpenSSF 的模型签名项目发布了 1.0 版本，随之而来的是 OpenSSF 模型签名（OMS）规范 —— 这是由 Google、NVIDIA 和 HiddenLayer 共同发起的一项努力，旨在为加密签名模型制品定义行业标准。这些设计决策值得深入了解，因为它们清晰地映射了模型与容器之间的实际差异。

加载中…