通用漏洞与暴露（CVE）系统是用于记录软件安全漏洞的全球标准。该计划由MITRE公司维护，并得到CISA的支持，为每个漏洞分配唯一的标识符和详细描述，有助于开发者、供应商及安全防御人员高效沟通，并针对已知风险及时采取应对措施。
随着 AI 模型逐渐成为企业系统的核心组件，安全领域开始提出一个问题： CVE 系统是否也应适用于 AI 模型？AI 模型暴露出一系列新的故障模式，例如对抗性提示、有害的训练数据以及数据泄露。这些现象看似漏洞，却不符合当前 CVE 的定义。根据 CVE 政策，漏洞必须是产品中破坏保密性、完整性或可用性保障的缺陷，而许多 AI 相关问题难以被纳入这一框架。
在多数情况下，将 CVE 分配给单个模型属于范围界定错误。真正的漏洞通常存在于加载和使用这些权重的框架与应用程序中。模型本质上是参数化的数学系统，作为二进制构件被载入到具备 API、工具和业务逻辑的框架内。安全漏洞往往出现在周边代码中，例如会话管理、数据处理或框架的序列化机制，而非静态的权重文件本身。
本文阐述了为何 CVE 通常应涵盖应用程序和框架，而不是 AI 模型。
当向模型提出 CVE 时，它描述的是什么？
提议的 AI 模型 CVE 主要可分为三类：
- 应用程序或框架漏洞：指存在于封装层或服务模型中的软件问题，而非模型本身的问题。例如，不安全的会话管理或框架层面的缺陷（如 TensorFlow 的 CVE 漏洞）。
- 供应链问题：包括模型权重被篡改、训练数据集被污染或代码仓库被入侵等风险。此类问题更适合通过供应链安全机制进行追踪和管理，而非依赖 CVE。
- 模型的统计行为：涉及数据记忆、偏差倾向或对对抗样本的敏感性等内在特性。根据 CVE 的定义，这些不属于安全漏洞，应在应用设计阶段通过适当策略予以缓解。
考虑 SQL 盲注的情况：漏洞并不在于 SQL 数据库本身，而在于未能对查询进行有效过滤的应用程序。通过 SQL 盲注，攻击者能够构造查询，逐步提取敏感数据，即使数据库完全按照预期运行。这种安全缺陷源于允许直接暴露原始查询接口的应用程序，而非数据库系统。
针对AI模型的对抗攻击和推理攻击遵循相似的模式：模型按设计正常执行推理，但外围应用程序无法有效控制访问或识别恶意查询。因此，任何相关的CVE都应针对应用层发布，而非针对模型权重。
AI 模型面临的各类攻击如何与 CVE 标准相契合或难以契合？
AI 模型是一种软件构件，但其固有的概率特性可能引发看似漏洞的行为。这些行为大多源于正常推理过程，但在不安全的应用上下文中可能被利用。
在评估是否应应用 CVE 时，有两个关键问题需要考虑。
- 该模型是否因违反安全属性而无法实现预期的推理功能？
- 此问题是否为该模型实例所独有，以至于分配 CVE ID 能帮助用户识别并修复该问题，而非仅仅重复描述一类适用于所有模型的通用攻击？
在几乎所有情况下，这两个问题的答案都是否定的。任何具备无限制访问权限的模型都可能面临模型提取、推理攻击、对抗性查询或数据投毒等风险。这些问题属于机器学习系统本身的固有特性，而非特定模型实例中的漏洞。在此发布 CVE 并不能带来实质性的可操作价值， merely 重申了 AI 模型对已知攻击类别的普遍脆弱性。
CVE 的存在旨在追踪那些独立且可修复的安全漏洞。大多数人工智能攻击技术通常会利用这些漏洞。
- 正常推理行为，指模型在将输入映射到输出的过程中，可能无意中暴露统计上的伪影。
- 系统设计缺陷，则指应用程序在缺乏访问控制、查询监控和输出过滤机制的情况下直接公开模型。
将这些漏洞归类为“模型漏洞”会削弱CVE的实际作用。正确的做法是将CVE范围限定在存在可被利用漏洞的框架、API和应用程序上。
以下攻击类别阐明了相关原因。这些类别通常被用作为模型发布CVE的依据，而在实际应用中，它们与应用安全及供应链安全密切相关。其中，训练数据的故意污染构成一个灰色地带，可能引发可复现的、针对特定模型的安全威胁。
攻击者如何提取模型权重或复制模型行为？这种情况是否构成安全漏洞？
此类攻击旨在未经授权的情况下提取模型权重或复制模型行为，典型示例包括模型窃取、部分权重提取以及下一个token分布的回放。其根本原因通常在于缺乏查询限制或输出信息过于详细，例如公开暴露的logits。模型本身执行的是正常的推理过程，问题主要出在应用程序或服务的访问控制机制以及输出处理方式上。
当模型泄露训练数据相关信息时，这是否构成 CVE？
在此类攻击中，攻击者试图从训练数据集中推断出敏感信息，主要技术包括成员推理（即判断某条记录是否被用于模型训练）和数据重建（通过诱导模型重新生成其记忆中的训练样本）。这些攻击利用模型的过拟合现象以及置信度信息的泄露，通过精心构造的输入实现目标。值得注意的是，模型在此过程中的行为仍符合其正常运行预期。因此，必须在系统层面采取相应的防御措施，例如引入差分隐私机制或实施查询监控，以有效缓解此类风险。<!–
强制性的错误分类对抗输入是否可能导致模型漏洞或系统缺陷？
这些攻击通过操纵输入，诱导模型产生错误分类或不期望的输出。在计算机视觉领域，难以察觉的微小扰动可能导致标签被错误翻转（例如将限速标志误识别为停止标志）。在自然语言处理中，越狱提示（jailbreak prompts）可能绕过安全控制机制。生成式模型也可能因对抗性提示而生成违规内容。尽管模型在训练过程中已固化其参数，但系统在应用阶段往往无法有效识别或拦截此类对抗性查询，从而导致防御失效。
如果恶意代码在模型加载过程中被执行，是否意味着模型本身存在错误？
许多所谓的“模型攻击”实际上是针对用于加载和运行模型的框架或文件格式的攻击。例如，某些攻击利用了支持远程代码执行的 Pickle 反序列化漏洞，或在前向传播过程中嵌入恶意代码的 Lambda 层载荷。这些问题源于不安全的序列化格式以及框架本身存在的缺陷，而模型权重本身并未被波及。通过将模型转换为更安全的格式或更换更可靠的框架，可以有效规避此类风险。相关漏洞的 CVE 归属于框架层面，而非模型权重本身。
何时使用有毒训练数据创建可能需要 CVE 编号的后门模型？
此类别代表了可能具有重要价值的单一边缘案例。攻击者可通过在训练过程中注入恶意样本，将后门或特定目标行为植入模型内部。例如，图像分类器可能因隐藏触发器而对输入产生错误标记，语言模型则可能因恶意提示而输出偏差内容。在这种情况下，模型在训练阶段即已被污染，而中毒的模型权重则成为一种离散且可追溯的痕迹。尽管许多此类事件可通过数据来源验证和真实性检查作为供应链问题加以应对，但蓄意植入后门的模型可能需要纳入 CVE 级别的跟踪体系。
CVE 在哪些场景中应用，以及如何追踪与人工智能相关的特定风险？
创建 CVE ID 的主要目的是跟踪和公开软件组件中的可利用漏洞，帮助开发者和安全团队对安全风险进行识别、评估、优先级排序和修复。
AI 模型本身不适用于此范畴。大多数攻击利用的是为模型提供服务的软件在推理过程中存在的预期行为或漏洞。在模型层面发布 CVE 会增加冗余信息，却无法提供有效的应对指导。
CVE 的合理适用范围是加载和公开模型的框架与应用程序。当存在可被利用的条件时，可以在这些层面实施补丁和缓解措施。唯一的例外是蓄意的数据投毒行为，例如在特定权重文件中植入可触发的后门。即便如此，这类问题通常仍可通过加强供应链完整性机制来更有效地应对。<!–
前进的道路十分明确：应在能够实现真正补救的环节应用 CVE，并通过加强供应链保障、访问控制和监控来完善周边生态系统。AI 安全的关键在于保护封装和服务模型所依赖的系统，而非将每一个统计属性都归类为漏洞。
如需了解 NVIDIA AI Red Team 的更多信息，请访问：NVIDIA AI Red Team 简介 | NVIDIA 技术博客。若发现 NVIDIA 产品中存在潜在安全漏洞，欢迎填写安全漏洞提交表单，或通过电子邮件联系 psirt@nvidia.com。
