AI 模型文件可能成为可执行的软件供应链威胁

一则 Google News 标题向安全负责人发出了直白警告：即使通过了常规软件审查，AI 模型仍可能跨越安全边界。冲突源于一种分类错误。企业往往将模型文件作为静态数据进行治理，尽管某些格式在加载时能够执行代码。

这条 Google News 结果 指向 Security Boulevard 的一则标题，称其中存在 CISO 可能未察觉的重大 AI 安全漏洞。该标题提供了一个有用的切入点，但其宽泛论断需要谨慎界定。可以合理确认的问题，并非某个新披露的、普遍存在的漏洞。

更大的问题在于，企业用于采纳 AI 的安全模型并不完整。模型检查点、适配器、辅助代码、提示词、智能体工具和凭证共同构成了一条新的供应链。围绕源代码包和容器镜像设计的控制措施，并不会自动覆盖这些组件。

这一缺口让 CISO 面临艰难现实。AI 团队重视快速试验以及便捷获取社区模型；安全团队则需要来源可追溯性、受限执行、资产清单，以及能够证明下载工件未被篡改的证据。

因此，核心矛盾并非 AI 创新与安全之间的对立，而是“模型只是数据”的承诺，与部署模型可能引入代码、依赖项、行为和特权访问这一现实之间的矛盾。

Google News 警告实际改变了什么

重要变化在于，模型引入如今应当接受与软件引入同等程度的审查。

Security Boulevard 的标题并未证明发生过单一入侵事件、存在受害者，或出现了新编号的漏洞。它凸显了一类暴露风险：当企业在生产环境中运行下载模型时，这类风险会变得更加严重。

这一区别很重要。耸动的解读可能暗示每个 AI 模型都具有恶意，或每位 CISO 都遗漏了同一个缺陷。现有证据并不支持这两种结论。

更狭窄、且有更充分依据的结论仍然影响重大：组织可以批准一个 AI 项目，却未充分审查其模型工件如何进入环境、如何被加载，以及如何在环境中运行。

模型检查点保存了恢复机器学习系统所需的参数和相关信息。一些常见检查点格式依赖 Python 的 pickle 序列化机制，该机制会在加载过程中重建已保存的对象。

这一重建过程可能调用函数。因此，恶意工件在反序列化时的行为可能不再像被动文档，而更像未经审查的软件。

反序列化是指将存储的字节重新转换为程序对象。当该操作通过攻击者控制的指令重建对象时，风险便会出现。

这并非在 Google News 标题出现后才编造出的理论性建议。PyTorch 明确警告用户，绝不要加载来自不可信来源的数据，因为其加载过程使用 unpickler。

PyTorch 在 2.6 版本中修改了 torch.load 的默认行为。如今，当调用方未提供自定义 pickle 模块时，框架会使用 weights_only=True。

受限加载器接受张量、基本数据类型、字典以及经过明确允许的对象。它还会阻止 Python 标准 unpickler 可执行的动态导入。

这一改动是重要的安全改进，也证明模型加载应当纳入组织的威胁模型。

PyTorch 自己的序列化指南指出，受限模式可缩小远程代码执行暴露面。它并不能防范所有拒绝服务或内存损坏场景。

兼容性带来了另一项复杂因素。旧检查点和自定义模型类可能无法在更安全的设置下运行，从而促使开发者恢复 weights_only=False。

由此出现的提示提供两条路径：团队可以重新设计或转换该工件，或者因为旧工作流依赖它而允许更广泛的执行。

在交付压力下，第二条路径看似只是无害的兼容性修复。但从安全角度看，它扩大了文件可能导致加载器创建或执行内容的范围。

正是在这里，标题对 CISO 的挑战变得具体。风险决策可能发生在笔记本、部署脚本或模型服务配置中，而不会进入正式的例外审批流程。

传统应用审查通常会询问：哪些软件包进入了构建，以及已知漏洞是否会影响它们。AI 审查还必须询问：每个模型工件由谁生成，以及它如何加载。

这一变化既是组织层面的，也是技术层面的。模型来源不再能只是数据科学家非正式关注的问题。

为什么 AI 模型安全落在现有职责边界之间

暴露风险之所以扩大，是因为没有任何一个团队会天然负责从发现模型到获得生产访问权限的完整路径。

机器学习工程师可能从公共仓库选择模型。平台团队可能将其打包，而云团队则提供计算资源和机密信息。

随后，应用团队将模型连接到客户数据。安全团队可能审查最终 API，却看不到此前关于工件加载的决策。

每位参与者都可能正确完成熟悉的任务，同时仍让组合系统暴露于风险之中。薄弱点存在于交接环节。

这解释了为什么这一问题可能对高级安全负责人仍不可见。模型下载可能不会像传统应用组件那样触发采购、依赖管理或变更管理控制。

下载的文件也可能通过间接渠道到达。某个库可能自动获取它，笔记本可能在运行时检索它，或者容器构建可能缓存它。

每条路径都会使资产盘点更加复杂。CISO 无法治理组织无法在开发、测试和生产环境中识别的工件。

开放模型仓库让试验变得更容易，但也改变了信任边界。仓库可用性并不等同于发布者经过验证、工件完整无损，或适合敏感工作负载。

Hugging Face 通过扫描上传至其 Hub 的 pickle 文件，解决了这一问题的一部分。其 pickle 扫描流程会分析上传工件中的操作，而不会执行文件。

这一控制措施可在仓库层面提供有用信息，但并不会将部署决策的责任转移给仓库运营方。

扫描可能遗漏新的规避技术。如果文件发生变化、工件由另一台主机分发，或部署代码获取了额外组件，扫描结果也可能失效。

因此，安全团队必须将仓库扫描视为一种信号。它不能替代内部来源检查、隔离、访问控制或运行时监控。

当模型需要自定义代码时，责任归属会更困难。一些仓库会要求用户允许远程代码，以便框架加载非标准架构。

自定义代码并不必然具有恶意。然而，启用它会将审查从数据加载决策转变为软件执行决策。

同样的担忧也适用于模型服务扩展、分词器、图像处理器和预处理脚本。模型文件只是已部署对象图的一部分。

智能体进一步扩大了这一缺口。AI 智能体将模型与能够执行操作的工具结合，例如查询数据库或编辑工单。

模型可能由可信提供商安全托管，而周边智能体仍可能拥有过多权限。反过来，一个权限严格受限的智能体仍可能继承来自不可信本地模型工件的风险。

CISO 需要同时具备两种视角。模型供应链安全关注系统由什么构成，而智能体安全关注运行中的系统能够做什么。

压力共同落在安全工程、机器学习运营、采购和应用所有者身上。任何一方都无法仅凭一份政策备忘录解决问题。

可行的责任模型会为每个生产模型指定一名负责的所有者，同时记录工件来源、摘要、格式、许可证、加载器、依赖项和获准用途。

摘要是文件的加密指纹。它让团队能够确认，经过审查的工件与进入部署流程的工件完全一致。

这些证据应当伴随模型穿过各个晋级阶段。否则，生产流水线可能会在同一仓库名称下静默获取更新后的文件。

这是应用于一种不那么寻常组件的常规供应链纪律。新颖之处在于组件的行为，而不在于对可追溯性的需求。

真正的冲突：模型是数据，还是代码

当团队假定模型只携带数学权重、不会带来可执行后果时，AI 部署就会失效。

这种假设看似合理。从概念上说，神经网络由已学习的参数组成，并由既定架构使用。

封装层使这一图景变得复杂。检查点可能包含张量、对象定义、优化器状态、元数据以及重建原始环境所需的引用。

pickle 之所以支持这种灵活性，是因为它能够序列化复杂的 Python 对象。同样的灵活性也使不安全加载变得危险。

恶意 pickle 载荷无需改变模型可见的性能。它可以在加载期间尝试执行操作系统命令，甚至早于评估人员向模型提出第一个问题。

这一顺序会绕过只关注模型输出的审查。准确率测试、安全提示和偏见评估，无法检测在初始化期间已经运行的代码。

另一条路径使用专门设计为存储张量、且不支持任意对象重建的格式。Safetensors 是为实现更安全、高效张量存储而开发的突出示例。

其结构将受限的元数据头部与原始张量数据分离。加载这种格式不会调用 Python pickle 指令。

这一设计消除了由 pickle 反序列化造成的特定任意代码执行路径，但并不意味着完整的 AI 系统值得信任。

safetensors 文件仍可能表示被操纵过的模型。模型可能在训练期间植入后门，或在特定触发条件下产生危险输出。

文件格式安全和模型行为安全属于不同层面。将任何一方视为完整保护，都会重现同一种分类错误。

这一差异也解释了为何扫描器本身无法解决问题。静态扫描可以检查文件结构和可疑操作，但无法保证模型行为无害。

反过来，行为评估也无法证明不存在不安全的初始化代码。安全需要在加载前、评估期间和部署后进行检查。

OWASP 将供应链薄弱点列为大型语言模型应用的主要风险之一。其 LLM 安全清单涵盖模型、数据、部署平台和外部组件。

这一更广泛的框架之所以重要，是因为 AI 服务不止包含一个检查点。它还包括推理软件、检索系统、插件、API 和数据处理层。

攻击者只需获得进入这条链路的一条可信路径。被攻陷的账户、遭篡改的制品、依赖替换或宽松的加载器都可能提供这种路径。

这使速度与保障能力直接形成张力。公开模型让团队无需等待供应商合同或漫长的训练周期，就能测试一个想法。

同样的便利性也鼓励了可变引用和未经审查的下载。一个仓库名称可能会成为经过验证的来源证明的替代品。

正确的应对方式并不是全面禁止开放模型。封闭式服务带来的是不同风险，包括对供应商的依赖、远程数据处理和有限的制品可见性。

安全负责人需要与每种部署路径相匹配的控制措施。托管 API 需要审查供应商、数据、身份和日志记录。

自托管模型则增加了制品来源验证、文件格式策略、隔离评估、依赖控制和基础设施加固的要求。与此同时，它也让运营方能更直接地掌控这些保障措施。

实际权衡很明确：自托管可以改善数据控制，但会将更多供应链责任转移给采用该方案的组织。

这种责任涵盖模型本身、其加载器、相关代码、转换工具和未来更新，并且会在初始安全审批后持续存在。

这正是为什么 Google News 的警告不应沦为一次性的清单项目。风险暴露会伴随每次模型修订和每项新集成。

更安全的格式可降低风险，但无法建立信任

安全的序列化格式能关闭一条执行路径，但无法解决来源、模型行为和部署权限问题。

当应用需要存储和加载张量权重时，Safetensors 提供了一个可靠的默认选择。其更为受限的格式避免了 pickle 所提供的通用对象重建功能。

PyTorch 的受限加载器则为兼容的检查点提供了另一种有用防御。两项控制措施都能降低加载模型时执行意外 Python 对象的可能性。

但这两项控制都无法回答是谁训练了该模型。它们也无法证明攻击者是否在模型分发前篡改了其权重。

恶意训练的模型可以在参数中隐藏行为。某个触发器可能导致定向误分类、数据泄露或特定的不期望响应。

这些威胁不同于 pickle 载荷。它们需要行为测试、来源证据和监控，而不只是文件解析。

模型转换同样值得谨慎对待。将不安全的检查点转换为更安全的格式，可能需要先加载原始文件。

如果转换发生在可信工作站或生产网络内，危险操作可能在安全输出生成前就已发生。转换需要在隔离、可弃置的环境中进行。

该环境不应拥有生产凭据和敏感数据。除非转换流程有已记录的需求，否则应禁用网络访问。

转换后的制品应获得新的摘要，并保留将其与源文件关联的记录。审查人员应保存扫描结果、转换日志和审批证据。

这些证据形成了一条监管链。它能帮助事件响应人员在后续发出警告时，确定哪些系统接收过某个特定制品。

模型仓库已经提供了有用的元数据、版本历史和扫描信号。企业应接入这些证据，而不是依赖开发者的浏览器历史记录。

更稳健的模式是将内部注册表作为生产来源。外部制品先进入隔离区，通过审查后获得不可变的内部标识符。

随后，生产系统仅从该注册表拉取已批准的摘要。它们不会获取外部某个分支或标签下当前出现的任意文件。

网络控制会进一步强化这一设计。模型服务工作负载在部署后不应需要不受限制的出站访问。

限制这种访问会降低隐藏下载器或凭据窃取载荷的价值，也更容易发现异常连接。

最小权限同样至关重要。模型进程不应仅因托管平台使用共享服务账户，就继承云管理权限。

只有在特定工具确有需要时才应注入密钥。代理应获得范围有限、任务级别的权限，而不是面向整个业务系统的通用令牌。

NIST 将安全且具韧性的运行视为可信 AI 的核心组成部分。其 AI 风险框架 强调在整个系统生命周期中持续开展治理、衡量、映射和管理。

这种生命周期视角能够避免一个常见错误：团队可能只批准模型一次，随后却允许自动更新，从而改变已经审查过的系统。

持续监控应能检测制品变更、加载器配置变更、新的出站连接以及对密钥的异常访问，也应记录代理操作。

日志需要包含足够的上下文，才能重建事件经过。若请求记录不包含模型版本、工具调用、用户身份和授权决策，其调查价值将十分有限。

然而，日志记录本身也会引入风险。提示词和输出可能包含受监管信息、个人信息或机密信息。

团队必须在收集一切信息之前，先定义保留、脱敏和访问策略。安全遥测不应成为敏感业务数据的无控制副本。

这一审慎观点仍然很重要：没有任何扫描器、格式或注册表能够证明 AI 系统毫无危害。

目标是实现可辩护的风险降低。组织需要分层控制措施，使入侵更困难、限制其影响范围，并保留响应所需的证据。

CISO 在下一次模型上线前应要求什么

最低可接受的控制措施，是从获批准的源制品到受约束生产进程的可追溯路径。

第一项要求是资产清单。每个生产 AI 系统都应标明其模型、版本、制品摘要、格式、来源、负责人、加载器和部署位置。

清单必须包括适配器和微调。基础模型可以保持不变，而适配器却能实质性改变其行为。

记录还应涵盖分词器、自定义代码、检索组件和外部工具。这些元素即使不改变模型权重，也可能改变安全结果。

第二项要求是接入门禁。团队应将外部制品下载到隔离区，而不是直接下载到开发工作站或生产构建环境。

当预期摘要存在时，门禁应对其进行验证。它还应检查文件类型、归档内容、签名和仓库安全信号。

不安全的序列化格式应默认拒绝。例外情况应说明为何更安全的格式或受限加载器无法支持该工作负载。

例外情况还应明确评估所使用的隔离控制措施。对知名上传者的信任具有参考价值，但并非完整的技术保障。

第三项要求是可复现性。部署流水线应引用不可变制品、依赖锁定文件、容器镜像和配置。

可复现性让防御人员能够重建经过审查的系统，也能减少测试与生产之间的静默漂移。

第四项要求是受约束执行。评估应在临时环境中进行，其中不应包含生产密钥、敏感挂载点或广泛的网络访问。

生产推理应在独立身份下运行。该身份应仅具备获批准用例所需的权限。

第五项要求是 AI 事件响应计划。响应团队需要用于撤销模型、禁用代理、轮换暴露凭据以及定位受影响部署的流程。

传统端点告警可能识别出运行可疑命令的容器。响应人员还必须确定是哪个模型制品和加载器启动了该进程。

第六项要求是问责。安全团队无法拥有每一项模型决策，但可以定义审批所需的证据。

模型负责人应证明其生产制品与经审查的摘要相符。平台团队应执行已批准的注册表和加载器策略。

采购团队应要求供应商说明模型来源、更新实践、安全测试和事件通知。合同措辞无法取代工程控制，但可以确立责任。

AI 物料清单可以支持这类记录。它将软件组件清单扩展到模型、数据集、框架和相关 AI 资产。

这一概念的标准化程度仍低于传统软件物料清单。组织仍应开始收集其能够验证的信息。

Cloud Security Alliance 已将恶意模型仓库描述为一个新兴攻击面。其 仓库分析指出，模型文件、周边代码和部署流水线构成相互关联的风险。

安全负责人应将这一担忧转化为可执行的平台默认设置。仅靠指导原则，无法战胜一条立即可用的 notebook 命令。

良好的默认设置会让获批准的路径更容易采用。团队应获得受支持的内部注册表、自动化扫描、转换支持以及可复用的隔离评估环境。

例外情况应当可见且临时。技术限制消失或有更安全的制品可用时，它们应当失效。

CISO 也应避免夸大这些控制措施的效果。干净的扫描结果并不证明模型行为安全，获批准的模型仍可能被滥用。

目标是建立受治理的部署路径。它能形成清晰的信任边界，并限制某一保障层失效时可能发生的后果。

三个可显示差距是否正在缩小的信号

下一阶段将通过更安全的默认设置、可验证的模型来源和可执行的运行时边界来衡量。

第一个信号是非可执行模型格式和受限加载器得到更广泛采用。PyTorch 的默认设置变更已经推动生态系统朝这一方向发展。

应关注企业平台是否会自动拒绝不安全的加载方式，也应关注开发者是否经常为了保持旧有兼容性而覆盖更安全的设置。

频繁覆盖将削弱乐观判断。这表明工作流摩擦仍会战胜安全默认设置。

例外率下降则支持相反的结论。这表明模型发布者和应用团队正在调整其打包实践。

第二个信号是可延续至部署阶段的模型来源证明。仓库元数据有所帮助，但企业需要与确切生产制品绑定的不可变内部记录。

应关注云平台和模型注册表是否通过标准部署工作流公开签名、证明、依赖详情和晋级历史。

证明是关于某一制品如何创建或检查的签名证据。其价值取决于签名背后的身份、流程和策略。

来源证明还应涵盖微调和转换。否则，已签名的基础模型仍可能导向无法追溯的生产衍生版本。

这方面的进展将强化这样一种观点：模型接入正在成为受治理的供应链。碎片化的元数据和可变引用则会削弱这一观点。

第三个信号是对代理和模型服务工作负载实现更好的隔离。这包括工作负载身份、工具级权限、出站网络策略和完整的操作日志。

Agent 的普及正将风险从生成文本转向实际执行的操作。一个能够访问电子邮件、源代码或财务系统的模型，可能造成的后果远不止回答不准确。

安全团队应关注供应商是否提供可供管理员测试和审计的权限边界。关于安全自主性的营销说法远远不够。

一项有效的控制措施应能显示：由哪个身份批准了操作、哪个工具执行了操作、哪个模型提出了建议，以及由哪项策略允许执行。

组织还应测试紧急停机流程。只存在于配置文档中的控制措施，可能会在真实事件中失效。

有证据表明定期开展隔离测试，将增强人们的信心。共享凭据和不受限制的工具则表明，Agent 的部署速度正在超过治理能力。

这三个信号应当结合起来看。更安全的文件可降低初始化风险，溯源信息可强化信任决策，而隔离机制可限制部署后的损害。

任何一项都无法单独提供完整保障。但三者结合，能够用一个可检查、可质疑的体系，取代隐性的信任模型。

如果 Google News 的标题能促使安全负责人提出一个更精准的问题，它就成功了。问题不在于 AI 是否带来某种抽象的未来危险。

眼下的问题是：每个已部署的模型是否都有明确来源、安全加载路径和受约束的身份。许多组织尚无法同时回答这三个问题。

这一验证缺口才是真正的安全漏洞。它存在于实验与生产之间，在那里，熟悉的工具带来了陌生的信任决策。

安全负责人应在本周选择一个已部署模型，并逆向追溯其来源。识别其摘要值、来源、加载器、自定义代码、权限和更新路径。

如果其中任何一个环节依赖记忆或未记录的开发者选择，组织就找到了可立即着手的工作。下一次 Google News 的警示，不应成为这条链路首次获得高管关注的时刻。