AI安全风险洞察：2024
威胁分析模型
近年来，人工智能技术在各个行业的应用迅速扩展，特别是在自然语言处理、机器学习和自动化决策等领域，AI已成为推动社会进步和技术创新的重要力量。无论是在金融、医疗、教育，还是在自动驾驶和智能客服等场景中，AI的应用无处不在。然而，随着AI系统的广泛应用，其潜在的安全隐患也逐渐暴露，如何确保AI系统的安全性，成为全球关注的关键问题。从数据隐私泄露、算法偏见到模型滥用和对抗性攻击，AI安全问题日益复杂且具有广泛影响，涉及到技术、伦理以及法律等多个层面。因此，AI系统的安全性不仅关乎技术的可持续发展，也直接影响到用户的信任和社会的稳定。
OWASP组织梳理LLM大模型的Top攻击场景，对10类风险场景识别安全威胁风险：
LLM安全威胁识别
LLM01: 提示注入 (Prompt Injection)
利用精心构造的输入，操纵大语言模型，导致意想不到的操作。直接注入会覆盖系统提示，而间接注入则会操纵来自外部的输入。Prompt攻击正是这种威胁的典型表现。
LLM02: 不安全的输出处理 (Insecure Output Handling)
当下游组件未经适当审查而盲目接受大型语言模型（LLM）输出时产生的漏洞。此漏洞会导致XSS、CSRF、SSRF、权限提升、远程代码执行等严重后果 。
LLM03: 训练数据污染 (Training Data Poisoning)
当LLM训练数据被篡改，引入漏洞或偏差，危及安全性、有效性或道德行为时，就会发生被数据投毒的风险。
LLM040.: 模型拒绝服务 (Model Denial of Service)
攻击者在大语言模型上进行资源密集型操作，导致服务质量下降或高成本。由于语言模型的资源密集性和用户输入的不可预测性，海绵样本作为一种特别的攻击手段，利用模型处理过量的请求，从而消耗大量计算资源，最终使得模型的性能和响应速度大幅下降。
LLM05: 供应链漏洞 (Supply Chain Vulnerabilities)
LLM 应用程序生命周期可能会受到易受攻击的组件或服务的影响，从而导致安全攻击。使用第三方数据集、预训练的模型和插件会增加漏洞。典型威胁为模型篡改。
LLM06: 敏感信息泄露 (Sensitive Information Disclosure)
LLM 可能在其回应中透露机密数据，导致未经授权的数据访问、隐私侵犯和安全漏洞。
LLM07: 不安全的插件设计 (Insecure Plugin Design)
LLM 插件可能存在不安全的输入和访问控制不足。这种应用程序控制的缺失使它们更易于被利用，并可能导致远程代码执行等后果。
LLM08: 过度代理 (Excessive Agency)
基于LLM 的系统可能会采取导致意外后果的行动。问题源于授予基于LLM 的系统过多的功能、权限或自主权。
LLM09: 过度依赖 (Overreliance)
系统或人员过渡依赖LLM 而没有进行监督，可能会因为LLM 生成的错误或不适当的内容，面临信息误导、沟通失误、法律问题和安全漏洞。
LLM10: 模型窃取 (Model Theft)
这涉及到未经授权的访问、复制或外泄专有的LLM 模型。其影响包括经济损失，竞争优势受损，以及可能接触到敏感信息。
这些威胁大致可以分为 开发态安全威胁、使用安全威胁 和 运行态安全威胁，并且在威胁分析中，通常会区分六种影响范围，针对三种攻击者目标（干扰、欺骗和泄露）：
泄露
损害训练/测试数据的机密性
损害模型知识产权的机密性（模型参数或导致这些参数的过程和数据）
损害输入数据的机密性
欺骗
- 损害模型行为的完整性（模型被操控以表现出不期望的行为，从而欺骗）
干扰
- 损害模型的可用性（模型无法正常工作或表现出不期望的行为——不是为了欺骗，而是为了干扰）
机密性、完整性和可用性（针对非AI特定资产）
这些威胁通过不同的攻击面产生影响。例如：训练数据的机密性可以通过开发阶段黑客攻击数据库被破坏，也可以通过会员推断攻击泄露，即通过将某个人的数据输入模型，并查看模型输出的细节，来判断该人是否在训练数据中。
安全威胁分类
开发态安全威胁
训练数据
数据泄露
数据投毒
模型安全
模型窃取
模型投毒
使用安全威胁
规避
模型窃取
模型逆向
数据泄露
成员隐私推理
模型拒绝服务
提示词注入
运行态安全威胁
模型安全
模型窃取
模型安全
输入数据
数据泄露
输出数据
不安全处理
应用框架
插件安全、权限控制
表格整理
| 资产与影响 | 攻击面与生命周期 | 威胁/风险类别 | 控制措施 |
|---|---|---|---|
| 模型行为的完整性 | 运行时 - 模型使用（提供输入/读取输出） | 直接提示注入 | 限制不希望的行为，输入验证，进一步的控制措施由模型本身实现 |
| 间接提示注入 | 限制不希望的行为，输入验证，输入隔离 | ||
| 规避（例如对抗样本） | 限制不希望的行为，监控，速率限制，模型访问控制，附加措施包括：检测异常输入，检测对抗输入，对抗鲁棒模型，训练对抗样本，输入扰动，鲁棒蒸馏 | ||
| 运行时 - 突破部署模型 | 模型中毒（运行时重编程） | 限制不希望的行为，运行时模型完整性，运行时模型输入/输出完整性 | |
| 开发阶段 - 工程环境 | 开发环境中的模型中毒 | 限制不希望的行为，开发环境安全，数据隔离，联邦学习，供应链管理，附加措施包括：模型集成 | |
| 训练/微调数据中毒 | 限制不希望的行为，开发环境安全，数据隔离，联邦学习，供应链管理，附加措施包括：更多训练数据，数据质量控制，训练数据扰动，抗中毒模型 | ||
| 开发阶段 - 供应链 | 供应链中的模型中毒 | 限制不希望的行为，供应商：开发环境安全，数据隔离，联邦学习；生产商：供应链管理，附加措施包括：模型集成 | |
| 训练数据的机密性 | 运行时 - 模型使用 | 模型输出中的数据泄露 | 限制敏感数据（数据最小化，短期保留，训练数据模糊化），附加措施包括：监控，速率限制，模型访问控制，附加措施包括：过滤敏感模型输出 |
| 模型反演/成员推断 | 限制敏感数据（数据最小化，短期保留，训练数据模糊化），附加措施包括：监控，速率限制，模型访问控制，附加措施包括：模糊置信度，小模型 | ||
| 开发阶段 - 工程环境 | 训练数据泄露 | 限制敏感数据（数据最小化，短期保留，训练数据模糊化），附加措施包括：开发环境安全，数据隔离，联邦学习 | |
| 模型机密性 | 运行时 - 模型使用 | 通过模型使用窃取（输入输出收集） | 监控，速率限制，模型访问控制 |
| 运行时 - 突破部署模型 | 直接模型窃取（运行时） | 运行时模型机密性，模型模糊化 | |
| 开发阶段 - 工程环境 | 开发阶段的模型窃取 | 开发环境安全，数据隔离，联邦学习 | |
| 模型行为的可用性 | 模型使用 | 模型服务拒绝（模型资源消耗） | 监控，速率限制，模型访问控制，附加措施包括：DoS输入验证，限制资源 |
| 模型输入数据的机密性 | 运行时 - 所有IT | 模型输入泄漏 | 模型输入机密性 |
| 任意资产，CIA | 运行时 - 所有IT | 模型输出包含注入 | 编码模型输出 |
| 任意资产，CIA | 运行时 - 所有IT | 常规的运行时安全攻击（对传统资产的攻击） | 常规的运行时安全控制 |
| 任意资产，CIA | 运行时 - 所有IT | 常规攻击（对传统供应链的攻击） | 常规的供应链管理控制 |
技术洞察
KCON：安全之眼大模型时代下的攻与防
LLM安全攻击框架
通过模型安全、应用安全、基座安全、身份安全总结出对应维度的攻击方法和手段。
| 安全类别 | 攻击方法 |
|---|---|
| 模型安全 | DAN、假定场景越狱、假定角色越狱、对抗性后缀攻击、Many-Shot越狱 |
| 应用安全 | 角色逃逸攻击、元提示词泄露、训练知识库文件泄露、间接提示词注入、CoT注入攻击、思维链干扰注入、思维链操纵注入 |
| 基座安全 | Agent运行容器逃逸、容器权限提升、集群权限接管、集群后门权限维持、集群安全防御绕过 |
| 身份安全 | AI大模型自身访问与权限控制、AI大模型环境各类组件框架访问控制与权限控制、AI大模型应用环境下各种Agent调度权限 |
LLM安全典型攻击手段
模型越狱攻击（Model Jailbreaking Attack）
模型越狱攻击（Model Jailbreaking Attack）是一种针对模型应用的常见攻击技术。这种攻击通常通过精心构造的输入（称为“越狱提示词”）来实现攻击，目的是绕过或者干扰模型自身安全与价值观的对齐限制，进一步诱导模型输出训练数据、隐私数据等敏感信息，以及恶意操作的执行。
CoT注入攻击——思维链操纵注入
通过观察CoT的调度过程，直接或利用对抗攻击手段构造恶意输入，实现对CoT过程的操纵，使模型跳过预置的CoT过程，直接调度敏感的Agent。
LLM安全防御手段
模型安全防御：自然语言的交互模式，让每个思路新奇的人都有了成为“黑客”的可能。为了更好系统安全，可以将安全防御进行前移，在模型训练、模型部署阶段，更早的保障引入安全防御措施。比如在模型训练阶段对数据进行清洗，对数据来源进行审核等措施，可以有效的抵抗数据投毒攻击。
针对传统应用业务与大模型组合场景，可以通过Prompt内容强化/结构强化等方式进行防御。
| 传统应用业务组件漏洞 | 组合传统应用安全防护技术方案 | 防御方法 |
|---|---|---|
| 业务模型应用安全风险 | 业务模型侧Prompt防御 | Prompt内容强化、Prompt结构强化 |
| 模型输入侧安全风险 | 应用平台侧输入防御守卫机制 | 基于规则的检测防御、基于模型算法的检测防御（LLMs模型、分类模型等） |
| 模型输出侧安全风险 | 应用平台侧输出防御守卫机制 | 基于规则的检测防御、基于模型算法的检测防御（LLMs模型、合规模型等） |
大模型供应链安全研究
Large Language Model Supply Chain: A Research Agenda
大语言模型（LLMs）在自然语言生成和代码生成等领域已经产生了深远影响。随着Agent应用范式的迅速发展，将LLMs集成到现实世界的应用中，以完成各种复杂任务，逐渐变得可行。然而，LLM应用的开发远不止是简单的模型部署或接口调用，它涉及开发、部署和维护过程中一系列第三方组件、框架和工具链的整合。这种复杂的供应链关系使得LLM系统软件容易受到各类漏洞的影响，进而威胁训练数据、模型及部署平台的完整性和可用性。
论文首次对LLM供应链进行了明确定义，并从软件工程（SE）和安全与隐私（S&P）两个角度回顾了供应链各阶段的现状，识别了当前的挑战，探讨了未来的研究方向，旨在为该领域提供有价值的见解与启示。
1. 研究背景
将LLMs集成到现实世界应用中需要一系列开发和部署工具链，如数据处理（如用于数据质量保证的Cleanlab和用于数据管理的Hugging Face Datasets）、模型训练（如用于分布式训练的PyTorch Distributed）、优化（例如，用于模型量化的 OmniQuant和用于模型合并的 MergeKit）和部署（例如，用于Agent工作流编排的AutoGPT和用于检索增强生成的RAGFlow）。这些工具链的引入导致LLM应用开发、部署和维护的各个阶段都面临供应链风险，OWASP已经将供应链漏洞列入LLM应用十大安全威胁之一。然而，以往的研究尚未对LLM供应链进行明确的定义，其中所面临的挑战和未来的研究路线也不明确。
2. LLM供应链定义
论文首先提供了LLM供应链的明确定义，包括三个层级，分别是：基础设施层，基础模型层以及下游应用生态。整个供应链涉及到的参与者包括上游数据提供商、模型开发社区、模型存储库、分发平台和应用市场，以及模型开发、分发和部署过程中的研究人员、工程师、维护人员和最终用户。
基础设施层：包括计算资源，数据集和开发工具链。计算资源包括模型训练和部署过程中所涉及的硬件资源，云服务，以及分布式系统。数据集包括大规模文本语料库（包括自然语言和代码）、专业领域数据集和多模态数据集。LLM工具链包括模型训练到部署的整个生命周期中所涉及的工具、第三方组件和框架。
基础模型层：以LLM开发生命周期的各个阶段划分，包括预训练、微调、测试、发布、共享、部署和维护。其中，模型发布和共享尤为关键，各种预训练模型的重用构成了模型依赖关系的基础。
下游应用层：主要是基于LLM的下游应用程序，例如聊天机器人、自主代理和特定领域的LLM解决方案。上游的工具链漏洞或者模型缺陷会通过供应链传递到下游应用中。
在LLM供应链中，存在多层级的依赖关系，简要介绍两种：一是继承自传统开源软件供应链的工具依赖，即开发工具链之间的依赖导致漏洞传播。例如，ShadowRay（CVE-2023-48022）漏洞导致数千台公开暴露的Ray服务器受到损害，受感染的GPU集群可能会被利用并部署挖矿软件。其次是来自于预训练模型和数据集复用的依赖关系。开发者通过模型/数据集共享平台（例如Hugging Face）来实现预训练模型/数据集重用，由此产生的模型/数据集依赖也会导致安全风险传播。近期的相关研究揭示了针对预训练模型/数据集的恶意代码投毒攻击实例，可能造成下游用户在加载模型/数据集是导致恶意代码执行。此外，模型或数据集中的偏见，毒性内容，幻觉，甚至后门也会随着模型/数据集依赖传播到下游模型乃至应用中，由于模型本身的黑盒特性，静态检测很难保证模型安全性。
3. 研究路线图
基于上述定义与分析，论文从软件工程和安全的视角来分析LLM供应链的现状，确定其中存在的关键挑战并且制定未来的研究路线。
3.1. 基础设施层
基础设施层所面临的挑战与快速发展的LLM生态密切相关，计算资源、数据集、工具链，任一环节的安全问题都可能传播到下游模型训练和应用开发过程中，造成严重的安全影响。
计算资源：硬件供应商单一过度依赖引发了潜在的供应链脆弱性，一些硬件级漏洞在LLM供应链中可能产生严重的安全后果。随着模型趋向更大更复杂，分布式系统和专有AI云服务已被广泛采用，但也引入了新的攻击面。最近，PyTorch的分布式RPC系统中发现了一个关键漏洞（CVE-2024-5480）。由于输入验证不足，可能允许当工作节点序列化并发送Python自定义函数（UDFs）到另一个节点时执行远程代码。
数据集：目前LLM供应链中的数据集具有前所未有的规模和多样性，并且对数据质量、偏见和隐私的关注日益增加。在代码大模型领域，开源仓库中的代码已成为训练数据的关键来源，这对代码质量、开源许可证和代码中潜在的安全漏洞都提出了更高的要求。此外，数据集管理组件中也可能存在潜在的安全漏洞，在数据集准备和模型训练工作流程中需要实施更严格的安全实践。
工具链：LLM的开发工具链包括许多新兴的第三方库、框架和专有工具。像Hugging Face的Transformers库可能在LLM供应链中引入系统性漏洞， PyTorch和TensorFlow等传统AI框架也常常会存在安全问题。例如，TensorFlow的Keras框架中Lambda Layer存在漏洞（CVE-2024-3660），允许任意代码注入，而PyTorch使用Pickle进行模型序列化也引入了潜在的反序列化漏洞。此外，针对LLM开发、部署和维护有许多新兴的开源框架或工具发布。LLM开发工具链的日益复杂，加上该领域的快速迭代，给整个LLM开发、部署和维护流程中的安全实践带来了巨大挑战。
3.2. 基础模型层
基础模型层主要关注于LLM训练，测试，发布和部署的相关内容。关于模型训练和测试部分，相关研究十分普遍，包括模型对齐，性能测试，可靠性测试（幻觉，事实一致性），安全性测试（提示注入，越狱攻击），道德和无害性测试（隐私，偏见等）。本文仅对模型内容安全方面的相关挑战进行了概述，重点关注于模型共享和发布阶段，强调模型复用衍生的一系列供应链角度的研究问题。
- 模型共享：在LLM供应链中，模型发布和共享构成了模型间复用与依赖的核心。像Hugging Face这样的平台目前已经托管了超过110万模型和24万数据集（截止11月22日），显著提高了模型和数据集开发过程中的协作性和可重用性。然而，供应链风险管理仍然是一个关键挑战，特别是在模型来源和安全保证方面。模型卡片和相关文档，往往无法准确反映模型的真实性质和能力。这种脆弱的模型来源验证使生态系统容易受到恶意模型投毒和其他形式的篡改。通过微调、模型合并等技术重用模型引入了复杂的模型依赖关系，可能导致风险传播。然而，当前的开源模型生态系统缺乏对这些相互依赖关系进行建模。模型本质上被视为黑盒，易受攻击的预训练模型可能隐藏着偏见、后门或其他恶意特征。除此之外，LLM的开源许可管理仍然是一个争议性问题，例如，围绕像Llama3这样的模型的许可条款对模型命名提出了严格要求，可能会出现一些许可合规性问题。此外，模型托管平台本身的安全性也值得关注。像Hugging Face平台上托管的模型转换工具这样的服务已被证明容易受到操纵，可能允许恶意代码被引入到LLM中。
3.3. 下游应用生态
下游应用生态直接面向用户交互，各种潜在的缺陷和安全问题都会直接暴露并且影响用户体验。目前，将LLM集成到现实世界应用中有各种各样的形式，我们主要以LLM对话系统和Agent代理来展开介绍。
LLM对话系统：由LLM驱动的对话系统和应用代表了LLM供应链下游生态的典型范式。这些应用利用LLM的能力，为不同领域提供交互式的智能解决方案。像GPT Store这样的平台正在成为集中枢纽，开发者可以在此发布他们的LLM应用（即GPTs），用户可以访问并使用这些工具来完成特定的任务和目标。这个生态系统与移动应用商店类似，旨在为LLM应用创建一个安全和用户友好的环境。LLM应用的普及降低了开发者准入门槛。然而，这种快速的增长和可访问性也引入了新的漏洞和治理挑战。随着这些平台的发展，它们必须应对LLM应用特有的新型安全威胁，如提示注入攻击和高级功能如函数调用的潜在误用。此外，LLM应用的独特性质，即能够实时生成和操纵内容，也对质量控制、伦理考量和法规遵从提出了前所未有的挑战。
LLM代理：LLM驱动的自主代理（ALAs）能够提供跨多个领域的自主或半自主任务执行。这些代理利用LLM的高级推理和知识合成能力来执行复杂任务，做出决策，并以复杂的方式与用户和系统互动。复杂的ALAs架构将LLM与外部工具、知识库和决策框架相结合。这些代理越来越能够以最小的人工干预执行复杂、多步骤的任务。例如，在软件开发领域，ALAs被用于代码生成、调试，甚至系统设计。然而，随着这些进展，关于越来越多的关于ALAs的伦理影响和潜在风险的担忧也在增长。一方面的安全挑战是存在易受攻击的代理逻辑。ALAs依赖于非确定性结果，验证代理行为是从逻辑上可能是不全面的，对手可以识别并利用代理逻辑中的漏洞来实现恶意结果。另一方面，基于LLM的代理可能会获得未预期的控制或决策能力水平，可能导致有害或未经授权的行为，对系统完整性、数据安全和用户安全构成风险。
4. 结论
LLMs的强大的生成能力和集成到下游Agent中完成现实世界任务复杂任务的潜力，使得围绕LLMs的系统软件生态日益繁荣。该生态中的各种开源制品（包括预训练模型、数据集、提示词和工具链）的复用和交互产生了一系列复杂的依赖关系，共同构成了LLM供应链。目前，围绕LLM供应链的相关研究尚处于起步阶段，缺乏系统的方向性指导。因此，本文提出了第一个全面的LLM供应链研究议程，通过对LLM供应链的组成成分和依赖关系进行定义，总结并回顾LLM供应链各部分的研究现状。在此基础上，本文通过软件工程和安全的双重视角对LLM供应链进行系统性分析，确定了LLM生态快速发展所带来的复杂挑战和研究机遇，并拟定了一个初步的研究议程，旨在为该领域未来的研究提供宝贵见解。
大模型基础设施风险
对项目大模型渗透测试过程中，我们可以通过prompt作为输入结合传统的攻击模式，可以组合成各种新的攻击路径，漏洞攻击入口为大模型的生命的周期的各个阶段，最终利用点为传统的安全漏洞利用模式。
| 攻击类别 | 攻击描述 |
|---|---|
| ModelHub数据集投毒 | NVDB-CNVDB-2023879241数据集加载时进行脚本注入，在远程加载数据集时，存在同名python脚本会自动导入运行，该漏洞可以同时影响HuggingFace平台和用户。 |
| 供应链投毒：模型、数据集、词表和知识库 | 除了数据集、模型、词表和检索知识库，都可能成为供应链投毒的目标。供应链攻击将风险转化为实际漏洞危害： CVE-2023-6730 RagRetriever.from_pretrained加载时的反序列化漏洞； CVE-2023-7018 AutoTokenizer.from_pretrained加载时的反序列化漏洞。 |
| ModelHub钓鱼和水坑攻击 | 任意HF平台用户可伪造组织、项目进行针对性邮件钓鱼和水坑攻击。 注册组织成本低、不在乎实名认证、恶意刷顶排行榜、滥用的信任关系、缺少完整性校验。 |
| 供应链模型后门 | 不同的模型框架支持不同的模型格式，模型文件除了数据外，还可能包含调用框架能力的代码。支持代码执行的格式包括pickle、onnx、safetensor等。 |
| TorchScript绕过安全策略 | TorchScript是一个用于将Python代码转换为可在C++环境中执行的序列化表示的工具，允许PyTorch模型导出为文件并在无Python环境的情况下执行。 NVDB-CNVDB-2024890770漏洞为C++处理TorchScript反序列化过程中存在越界访问漏洞。 |
| 分布式网络基础设施漏洞 | PyTorch中的分布式RPC组件漏洞，PyTorch分布式RPC用于支持分布式训练和推理，允许不同设备或进程之间高效通信和协作。 CVE-2024-5480漏洞，攻击者可通过操作RPC调用，利用内置Python函数执行任意代码，从而完全控制主节点。 |
| NCCL集合通信库漏洞 | NCCL是一个高性能的多GPU通信库，专为GPU加速设计，旨在简化多GPU和多节点系统中的数据同步和传输。 NVDB-CNVDB-2024857163漏洞，未授权访问网络端口导致内存越界访问，可能导致远程代码执行。 |
| Triton-Inference推理框架漏洞 | CVE-2023-31036，API接口存在任意文件写入漏洞，攻击者可覆盖模型配置文件，将任意文件写入，从而升级为远程代码执行。 |
| Ray计算框架漏洞 | Ray是开源分布式计算框架，为并行处理提供计算层，用于扩展AI与Python应用程序。 CVE-2023-48022，ShadowRay访问Dashboard的API接口提交任务，导致远程代码执行。 |
BlackHat议题
- [BlackhatUSA’24] 实战LLM安全：一年来的实战经验 [链接] [幻灯片]
- [BlackhatUSA’24] 隔离还是幻觉？为乐趣和权重攻击AI基础设施提供商 [链接]
- [BlackhatUSA’24] 从MLOps到MLOops - 揭示机器学习平台的攻击面 [链接] [幻灯片]
- [BlackhatASIA’24] LLM4Shell: 发现并利用在真实世界中LLM集成框架和应用中的RCE漏洞 [链接] [幻灯片]
- [BlackhatASIA’24] 混淆学习：通过机器学习模型进行供应链攻击 [链接] [幻灯片]
- [BlackhatASIA’24] 如何让Hugging Face拥抱蠕虫：发现并利用不安全的Pickle.loads在预训练的大型模型库中的漏洞 [链接] [幻灯片]
洞察总结
从业界技术洞察可以看到，大模型的攻击越狱手段不断增加，对内容安全有较好的攻击及自动化攻击思路，其他的RCE攻击模式，主要还是依赖传统的安全漏洞与大模型特有的Prompt相结合。
针对建设蓝队的正向安全能力，可以根据AI系统的各个组件进行分类，包括数据组件、算法模型、AI框架组件和基础设施组件，进而总结出AI系统的核心资产：原始数据、预处理数据、已标注数据、训练数据、增强数据、验证数据、测试数据、用户输入数据、RAG数据、推理数据、数据预处理算法、模型超参数、训练算法、模型参数、已训练模型、已部署模型、已下线模型、生成AI模型所需的工具和平台、系统部署所用的工具和平台、训练设施以及部署设施等。根据这些资产的类型，可以构建相应的威胁模型。
以已部署模型为例，这些模型已经完成了训练和测试，并被集成到实际应用或生产环境中，能够处理真实世界的数据并提供预测或决策支持，如回归分析、预测和异常检测等任务。部署是机器学习生命周期中的关键环节，涉及将模型从开发环境迁移到生产环境。
在此过程中，模型和相关组件可能面临多种安全威胁，包括但不限于以下类型：
模型窃取攻击
模型逆向攻击
数字对抗样本攻击
物理对抗样本攻击
模型提取攻击
提示词注入攻击
目标劫持攻击
提示词泄露攻击
提示词越狱攻击
属性推理攻击
数据重建攻击
成员推理攻击
海绵样本攻击
模型文件篡改攻击
模型倾斜攻击
不安全的任务规划（AI智能体）
模型非授权获取