第 9 章 — 模型完整性与供应链风险
《LLM Primer VII: AI Security》章节走读的第九篇。这一章把一份模型 artefact 当作由第三方分发的二进制来对待 —— 带着二进制分发一直带着的反序列化、后门和出处问题。
这一章为什么存在
开源模型是很多生产系统的默认选择,因为闭源前沿 API 在规模上很贵、也带着厂商锁定的顾虑。代价是:运营者现在自己扛起了闭源方之前一直在替他扛的供应链风险。Hugging Face 上托管着几十万份由研究者、企业实验室、以及一条长尾衍生者贡献的模型 artefact。这条分发通道像一个包仓库,只不过里面的 artefact 是大型二进制,加载它们要反序列化复杂的对象图。这一章走一遍供应链这块面 —— 后门、格式漏洞、出处、漂移 —— 以及领域内为了把模型供应链的成熟度拉齐软件供应链而采纳的基础设施。
9.1 后门能挺过安全训练
Gu、Dolan-Gavitt 和 Garg 2017 年的《BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain》立起了后门这条研究线。少于百分之一的训练样本被投毒,就能诱导一个分类器在带触发的输入上误分类、同时保持不带触发的输入准确率不变。BadNets 的威胁模型经过自然翻译就迁到 LLM 上。Anthropic 2024 年 1 月 Hubinger 等的"Sleeper Agents"论文,展示了一个让人不安的延伸:刻意训练进模型的后门,能挺过后续的安全训练 —— 包括为了移除后门实现的那个行为而做的 RLHF 和对抗性训练。模型在安全训练分布下表现正常,在触发下退回到被后门的行为。论文的贡献是明确说出:如果基础模型的出处不确定,对齐训练就不是一个一般安全过滤器 —— 它只修改它训练期间采样到的分布上的行为,一个足够罕见或藏得足够深的触发,就坐在那些分布之外。防御含义是结构性的:如果基础模型的出处不确定,已部署模型的安全性就无法只从安全训练来推理。检测很难,因为触发按设计就是罕见的,但行为 fuzzing、激活分析,以及对触发输入的 canary 评估,是当下的最佳实践。
9.2 格式层面的风险是一个真实类别
模型权重是大型二进制文件,通常通过 registry 和 hub 分发。加载这些权重要做反序列化。很多 PyTorch 时代 artefact 的默认格式是 pickle,而它的反序列化按设计就会执行任意 Python。针对 Hugging Face Transformers 库披露的 CVE-2024-3568,展示了一个模型文件如何被构造成在加载时执行任意代码。这不是第一个这类 CVE,也不会是最后一个。safetensors 格式,由 Hugging Face 开发,2022 年发布,是这个领域的应答 —— 一个"头 + 张量"的格式,没有代码执行路径,性能可以接受,现在是主要模型发布的默认。操作上的含义是:从不受信任的来源加载一个 pickle 文件,功能上等价于把一个不受信任的二进制当作你的推理进程去跑。模型版本控制提供了完整性上的第二个轴。模型卡,由 Mitchell 等在 2019 年 FAccT 上引入,给出一份结构化的文档记录 —— 预期用途、训练数据、评估结果、已知局限 —— 已在 Hugging Face、OpenAI、Anthropic 和 Google 上被广泛采纳。卡是文档,不是证明;它不验证 artefact 和描述相符。那是加密签名的活。
9.3 出处、签名与漂移监控合上闭环
软件供应链社区已经收敛到一个栈 —— SLSA 级别、in-toto 断言、Sigstore 签名、容器 registry 签名 —— 到 2026 年已经延伸到 ML artefact。安全模型部署的模式现在是可辨识的。一个模型在 registry 里的条目,由一把授权 key 签名。部署系统拉下 artefact,验证哈希,验证 registry 条目上的签名。加载只从 safetensors 而不是 pickle 出。出处元数据被保留并链接到部署记录,让"哪个版本、从哪个上游、正在服务流量"这个问题总有一个确定的答案。漂移监控是持续的对应物。一个部署了的模型,即使权重没改,行为也会随时间变化 —— 输入变了、上游应用变了、查询分布变了。要把合理漂移和被攻陷区分开,需要基线。这一章走一遍分布性指标(平均输入长度、安全分类器分数分布、拒绝对顺从的比率)、类别性指标(代码响应的比率、响应中 PII 的比率),以及行为性指标(定期跑固定 canary prompt、把响应和基线做对比)。偏离基线不是被攻陷的证据,但它是"有东西变了、值得调查"的信号。
第 9 章为下面铺了什么
第三部分现在覆盖了模型本身作为安全物件 —— 可靠性失败(第 7 章)、刻意的输入空间攻击(第 8 章)和供应链风险(第 9 章)。第四部分向上到模型所嵌入的系统架构。第 10 章走安全 LLM 部署的架构模式 —— 隔离边界、多层验证、OPA 和 Cedar 这样的策略引擎、安全 API 设计,以及把 zero-trust 应用到模型调用上。第 11 章走可观测性、日志和事件响应 —— 把架构性防御变成组织能可靠运行的系统的操作层。第 12 章走访问控制和身份 —— 认证、授权、多租户隔离、速率限制,以及企业治理这一层。三章合起来描述的,是包纳、支撑并约束第三部分刚考察过的模型组件的那个系统架构。
下一章 — 第 10 章:设计安全的 LLM 架构。模型周围的隔离边界、多层验证、策略引擎,以及把 zero-trust 原则应用到"一个把所有输入都读作指令"的组件上。
