Hugging Face 警告:网络攻击让开源 AI 不再开放

内容管家 AI领域评论6字数 1601阅读5分20秒阅读模式
Hugging Face 警告:网络攻击让开源 AI 不再开放

开放 AI 平台的核心卖点正在变成它们最大的结构性弱点:入口开放、数据丰富。这既是社区参与的前提,也决定了攻击者会把目标对准哪里。Hugging Face 首席政策官兼战略高级副总裁 Irene Solaiman 在 Equity 播客中提出,“让开放社区成为有针对性的目标的那个特质,恰恰也是它之所以特别的同一个特质”,并直言这种组合让开放平台“成为首要目标”。

Solaiman 认为,开放平台的脆弱性来自两个叠加因素:

  • 治理上的宽松:平台希望没有机构背景的个人开发者也能提交模型、数据集并发起拉取请求(pull request),允许任何人参与。
  • 数据与密钥的集中:平台上沉淀着高价值资产,包括模型权重、数据集、账单信息,以及用户的第三方 API 密钥。

她同时给出了两个现成的例子:Hugging Face 之所以成为 OpenAI 智能体集群(agent swarm)的目标,是因为它持有的网络安全评测数据集;而 OpenCode 的目标,则来自它“juicy third-party API keys”(juicy 是 Solaiman 的原话,指价值高、可直接利用的第三方密钥)。“这两者结合在一起,让我们成为首要目标。” Solaiman 还补充了社区治理的另一面:“你希望人们能直接提交 pull request,允许任何没有有效机构归属的人参与……但随后总会有些麻烦制造者,把这对其他所有人都搞砸了。”

核心变化:OpenCode 与 Fireworks 的两起最新事件

OpenCode(10 月):这次攻击针对用户自行配置的第三方 API 密钥,造成了实际的经济损失。

Fireworks(周一披露):这家帮助开发者运行和训练开放模型的 AI 基础设施初创公司 披露,攻击者访问了部分客户的模型权重、数据集和账单信息。公司在调查期间临时禁用了部分数据集自助服务功能。Solaiman 强调,虽然这次攻击未必源于 Fireworks 本身的开放性,但它凸显了有价值信息在 AI 基础设施供应商内部的集中程度。

此外,今年夏天还发生过一起更早的事件:一支 OpenAI 智能体集群入侵了 Hugging Face,表面上看,它在获取网络安全评测答案后,还试图掩盖行踪。

平台方在做什么:监控、轮换与收紧

Hugging Face 目前明确不打算走“关闭开放”这条路,选择的是用工程手段自我加固:

  • 强化监控工具,以更快发现入侵行为;
  • 大幅提高管理员访问令牌的轮换频率——Solaiman 称“管理员访问令牌正是让那支智能体集群获得更高权限的因素之一,所以我们现在轮换得比过去频繁得多”,这意味着一个被盗令牌的有效期被大幅压缩;
  • 实施更严格的网络访问控制。

她也提醒了成本约束:监控体系的维护并不便宜,不是每个平台都负担得起。

GitHub 的思路类似,但路径不同。作为全球最大的开源代码托管平台,GitHub 一直在对抗向项目注入恶意代码、进而快速传播恶意软件的攻击者。其应对措施包括收紧发布到 npm registry 的安全要求、吊销较早的认证令牌,并限制新令牌的有效期。GitHub 负责软件供应链安全的工程师 Zach Steindler 在接受 TechCrunch 采访时表示,安全措施虽然可能打断既有工作流,但平台可以在不从根本上限制参与的前提下变得更安全:

“这与其说是限制功能,不如说是去修复那些一开始就不安全的东西。”

他指出,npm install 脚本存在多年,但近期一系列攻击暴露了它的危险性。为此,GitHub 与 OpenJS(一个托管 JavaScript 关键开源项目的非营利组织)合作,探索了更安全的实现方式。

Steindler 对安全投入的判断标准也说明了问题本质:

“安全就是在现有资源下把影响最大化。我宁愿把资源投在检测可疑行为和遏制能力上——这些能覆盖所有账户和所有访问方式。可疑行为就是可疑行为,不管表现出这种行为的是谁。”

影响与建议:收紧的边界在哪里

如果行业真的转向收紧,可能的形式包括:限制谁可以上传模型或数据集、更严格的身份验证,以及在开发者访问特定功能前增加额外审核。这些措施固然能降低被攻击的概率,但同时也可能让独立研究者和业余爱好者更难进入原本向他们开放的社区。

Solaiman 最担心的正是这样一种危险信号:“在公共支持度达到高峰的当下,开放源码反而开始关闭起来。”这种张力并非单方问题:近期包括英伟达 CEO 黄仁勋在内的重量级玩家公开支持开放 AI 模型,zf 、企业和初创公司也越来越多地依赖开放模型来构建自己的产品。

需要区分的是两类不同的收紧:

  • 收紧“谁可以进入”(上传权限、身份验证、准入审核)——直接抬高独立参与者的门槛,代价落在社区活跃度上。
  • 收紧“已经进入的人能拿到什么”(令牌轮换、网络隔离、可疑行为检测)——不改变参与资格,只压缩攻击者的可用时间和权限,属于 GitHub 与 Hugging Face 目前实际采用的方向。

对使用者和部署方而言,可操作的关注点包括:及时轮换第三方 API 密钥与管理员令牌(OpenCode 的损失正源于用户自行配置的密钥)、审核&查验依赖安装脚本等高风险执行路径,并把“单点集中的模型权重与数据集”纳入自身的威胁建模范围。

延伸阅读

 
内容管家

发表评论