开源AI模型与开放权重 AI 模型引发的思考

原创

CSOonline
CSOonline

安全行者老霍

2026年10月13日 08:00
美国

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

作者：Francis Brero

发布时间：2026年10月2日|

代码规模的剧增意味着风险暴露面的扩大，而成本压力正将企业推向未经严密审查的模型。

在面对典型的网络安全风险暴露时，我可以使用确定性的工具进行渗透测试。我能够预测一款软件将如何响应，甚至有很大的把握在漏洞被利用来攻击我之前将其找出。

然而，我们现在所面临的是一种全新的风险暴露。对于大语言模型（LLM）和 AI 模型而言，存在着使用传统网络安全方法无法扫描且几乎无法检测的隐形风险。不良企图者能够以一种如今难以测试的方式，将恶意或非预期的行为嵌入到模型内部。

这不仅打碎了原有的工具链，还打破了一些不那么显而易见的东西：供应商关系。我们名单上的每一家网络安全供应商都声称自己是企业的“思想伙伴（thought partner）”。现在正是检验这一声明的时刻，因为针对“你们如何对其进行扫描”这个问题的诚实回答是：没有任何人能够完全做到。合同依然建立在控制措施的有效性、架构、证据和响应能力之上--这是理所当然的。但我正在增加一个“否决项（disqualifier）”：如果一家供应商无法在一个我们谁都还没绘制完威胁图谱的领域教会我一些东西，那么无论他们在其余项目上的得分有多高，我都不会希望由他们来解决这个难题。

在顶级的 AI 前沿模型（frontier models）与未经严密审查的开放权重（open-weight）模型之间做出抉择是一项艰巨的任务。两者在定价结构、隐藏的运维开销和运营风险方面存在着巨大的差异。无论我们是否选择顶级模型，成本压力都是客观存在的。但是，当我们引入一个无法审查其来源（provenance）的模型时，需要考量的重大威胁也是显而易见的。

1. 开放权重“神秘配方”的固有风险

开放权重模型提供了可在本地运行和微调的最终模型，但它们通常缺乏对用于创建它们的训练数据和脚本的透明度。在许多情况下，开放权重 AI 的“配方”缺失了一些关键成分。

开源模型（Open-source models）则被寄予了更高的标准。开源促进会（OSI）的定义要求提供详细的数据信息、训练与推理代码、参数，以及赋予使用、研究、修改和共享自由的许可协议。它并不要求重新发布每一条训练数据，但确实要求提供足够的信息，以便有能力的第三方能够审查该模型是如何诞生的。代码或源材料的可获得性（Source availability）并不等同于可测试性（testability）：没有人会认为审计一个大型模型是简单直接的。它带给我们的，是提出有根据的问题的能力--而这恰恰是开放权重所剥夺的。

这种区别比行业内松散的词汇所暗示的更为重要。大多数被称为“开源 AI”的东西本质上都是开放权重：即一个源头未知的、可下载的构件（artifact）。我们并不是在审查一份配方，而是在信任一道做好的菜肴。

尽管开放权重模型变得越来越普遍，但这其中存在权衡。这种数据透明度的缺失带来了更大的风险，这些风险表现为后门（backdoors）和数据中毒（data poisoning）。像嵌入在开放权重模型数值参数中的隐蔽关键短语这样简单的事情，就可能触发恶意行为。对于最终用户来说这是无意的行为，但对于模型的发布者来说可能完全是蓄谋已久。

在此，我想对现有证据的状态保持精确，因为讨论通常会在这个地方变得含糊不清。我们在实际环境中观察到的是代码库恶意软件（repository malware）：JFrog 记录了 Hugging Face 上恶意的 Pickle 序列化模型，这些模型会在加载时执行代码。这是一场真实的攻击，也是一个我们已经知道如何修复的打包层面的问题。而潜在的行为后门（latent behavioral backdoor）--即存在于参数中的触发短语--迄今为止仅在受控研究（如 Anthropic 的《Sleeper Agents》工作）和概念验证（如 PoisonGPT）中得到展示，尚未在生产环境的大规模数据泄露中被记录。

但是，如果我们看看这项研究已经做到了什么：在《Winter Soldier》研究中，团队对少于 0.005% 的预训练 Token（64 份文档）进行了投毒，并成功让模型学会了一对在训练数据中完全未曾出现过的隐藏“提示词-响应”对。审计语料库根本无法发现它，因为它从未被写下来过。虽然这还不是生产规模的威胁，但它证明了该技术是有效的，只是在等待有人将其变得更加隐蔽。

这才是值得围绕其制定计划的部分。检测不对称性（detection asymmetry）对我们极为不利：这些行为能够在安全训练（safety training）中幸存下来，而在权重中搜索它们所消耗的算力，将超过我们大多数人所能承受的极限。我们现在正在为一个一旦到来我们甚至无法察觉的东西挑选供应商，而这正是一场建立在这种不确定性之下的赌博。

Meta 最近发布了 Muse Glimmer--一款采用 Apache 2.0 许可协议的 300 亿参数模型，并计划开放其旗舰模型 Muse Spark 1.2 的权重。需要注意的是，大多数媒体报道都将 Glimmer 称为开源模型。但它是开放权重：Meta 发布的是参数，而不是训练数据或训练代码。行业媒体中的这种概念混淆，同样也出现在我们的架构审查中，这两个地方都值得注意。

2. 评估网络安全问责制

当发生重大网络安全事件时，究竟是谁的责任？如果我们使用的是来自 OpenAI 或 Anthropic 的顶级模型，确定网络攻击的责任归属相对直接。这也是选择大型前沿模型的主要优势之一。

但另一种选择呢？如果我们从 Hugging Face 上下载了一个开放权重模型，然后发生了网络灾难，谁来承担责任？合同的另一端没有供应商。开放权重模型以顶级模型所没有的方式打开了法律责任的大门，而这项责任最终落在了 CSO（首席安全官）的头上。

3. 解构顶级模型 vs 开放模型

解决方案是制定更严格的防护栏（guardrails）。我们目前有两个选择：要么选择顶级模型以完全避开开放权重；要么采用开放权重模型，并针对这些威胁构建防御体系。后者需要投入真实的时间和资源。

选择前沿模型听起来更容易，但这是有成本的--与开放权重提供商相比，我们为使用 Anthropic 或 OpenAI 所支付的价格可能是后者的 10 倍。对于所有人来说，更高的前期成本并非都是可行的。

那么，对于我们当中选择开放权重路线的人来说，我们该如何防范恶意行为？部分逻辑在于要理解：我们可能无法阻止触发器（trigger）的激活，但我们可以阻止动作（action）的执行。如果权重是无法扫描的，那么控制杠杆就转移到了下游--即允许该模型做什么。

这意味着需要明确指定：在没有用户批准的情况下，我们的模型不能采取某些特定操作。这很棘手，因为恶意活动可能简单到只是访问一个网站（提供心跳信号，随后激活毒性行为）。我们可以通过仅允许模型访问经过审查的域名来缩小这一范围。这一切都不是万无一失的，而这也正是为什么它应该出现在与我们合作的每一家网络安全供应商的对话中。

4. 将网络安全对话转化为 CSO 的机遇

即便这些日益难以察觉的威胁近在咫尺，风险暴露的前景也并非全是阴霾。我们拥有降低风险和防止恶果发生的切实机会，而其中大部分都贯穿于我们已经付费的供应商之中。

当我们审查网络安全合约定期时，应该考虑到攻击向量已经发生了根本性的变化。生成比以往想象中更多的代码，创造了前所未有的更多风险暴露，其规模与以往的威胁相比简直是天壤之别。

我们的供应商或许能够分析比过去人类能分析的更多的代码。但是，将诸如代码审查审计和渗透测试等人类方法放大到与 AI 代码生成的规模相匹配，是有其局限性的。要求一个自动化系统去做人类能做的事（仅仅是速度快得多），并不能填补这一鸿沟。

另一种选择是承认：这些系统具备根本不同的能力。如果它们能够处理非结构化、非确定性的数据，我们该如何重新思考网络安全？我们该如何评估系统行为背后的意图（intent），而不仅仅是测量确定性的输出？

这就是要抛给我们供应商的问题。仅仅增加 AI、扩大规模、更快地做更多事情并不是一个令人满意的答复，因为它用更多的数量去回答了一个数量问题，而更难的问题在于：我们再也无法通过阅读构件本身来证实其行为的安全性了。询问他们在模型进入生产环境之前要求什么：验证过的发布者、锁定的版本与哈希值、安全的序列化、对实际运行内容的盘点。询问当模型在运行时要求执行有重大影响的操作时会发生什么，以及模型之外由谁授权。这些回答会告诉我们，他们究竟是思考过这个问题，还是仅仅在重新打包一个扫描器。

这一切都不能替代合同续约的常规依据。但是，一个无法展开这种对话的供应商是在向我们传达某种信号，而我会严肃对待这一点。如果他们对这些关键问题没有好的答案，那绝不是我会为其续约的网络安全供应商。

https://www.csoonline.com/article/4229623/rolling-the-cyber-dice-with-open-source-and-open-weight-ai-models.html

（完）