AI 安全工程

AI 供应链安全与模型完整性

您的模型就是可执行代码。大多数组织却把它们当作数据文件对待。正是这一差距引发了安全漏洞。

$4.63M

涉及影子 AI 的平均数据泄露成本

IBM《2025 年数据泄露成本报告》

83%

的组织缺乏自动化的 AI 安全控制措施

Kiteworks 2025

352K

在公共注册库的 51,700 个模型中发现的不安全问题

Protect AI 2025

大多数安全计划忽视的攻击面

AI 模型并非静态构件。它们是在加载、训练、推理和智能体执行期间运行的代码。四类攻击主导着威胁模型。

Pickle 格式问题

torch.load() 在反序列化过程中执行任意 Python 代码。这不是一个漏洞,而是 pickle 序列化的设计行为,并且 80%+ 的 ML 模型都在使用它。

在 Hugging Face 上,一个名为 "baller423" 的模型被发现正在向 Kreonet 建立反向 shell。该模型看起来很正常,通过了基础扫描,却在有人加载它的那一刻运行了任意代码。

PickleScan 作为使用最广泛的防御手段,至少存在 3 个已知的零日绕过漏洞(CVE-2025-10155)。基于黑名单的扫描从根本上就是失效的,因为攻击者掌控着序列化格式。

微调摧毁安全性

Llama 3.1 8B 在提示注入抗性上从 0.95 降至 0.15 ,仅仅经历一轮微调即如此。这意味着安全对齐在正常的、非对抗性的训练后退化了 84%。

几乎没有人在微调之后重新评估安全性。模型通过了初始的安全评估,在领域数据上接受微调,然后在防护栏实际上已被移除的情况下进入生产环境。这并非什么奇异的攻击,而是大多数组织的默认工作流程。

影子 AI 蔓延

98% 的组织存在未经授权的 AI 使用。这个数字并非笔误。影子 AI 事件额外带来的 $670K 泄露成本反映了一个简单的现实:你无法保护你看不见的东西。

62% 的安全团队无法识别其环境中 LLM 的部署位置。开发者从 Hugging Face 下载模型、用个人密钥调用 OpenAI API、在个人云账户上部署微调后的模型。当前的安全工具大约只能呈现其中 38% 的此类活动。

智能体 AI 放大效应

GitHub Copilot 的 RCE 漏洞(CVE-2025-53773,CVSS 7.8)通过 YOLO 模式,将代码库文档中的一处提示注入变成了对整个系统的完全攻陷。智能体读取了一条恶意指令,将其作为代码执行,用户的机器随即被攻陷。

Amazon Q 的 cleaner.md 文件通过智能体的上下文窗口向 950K+ 用户分发了破坏性命令。OpenClaw 的市场在 63 天内累计了 138 个 CVE,提交的技能中有 12% 被发现是恶意的。

智能体之所以会把提示注入升级为系统级攻陷,是因为它们拥有传统 LLM 所不具备的工具访问权限、凭据和执行特权。

AI 模型安全领域各方分工

供应商生态正在快速成熟。以下是对每一方覆盖范围及其遗留空白的诚实审视。

供应商 他们做什么 他们不做什么 最适合
Palo Alto / Protect AI 模型扫描、AI-BOM 生成,已集成至 Prisma AIRS 平台 架构设计、定制流水线工程、组织变革管理 已部署在 PANW 平台上的企业
HiddenLayer 运行时 AI 检测与响应、智能体安全监控 供应链架构、ML-BOM 实施、合规映射 正在增加 AI 可见性的 SOC 团队
JFrog MLSecOps、模型注册库安全、Hugging Face 集成 对抗性红队演练、安全对齐验证、治理设计 管理模型构件的 DevOps 团队
Wiz 云安全场景下的 AI-BOM、模型扫描 本地部署模型安全、微调安全、智能体架构 云优先型组织
NVIDIA NeMo Guardrails 面向 LLM 的开源运行时 guardrails 模型扫描、供应链安全、溯源追踪 构建定制 LLM 应用的团队
四大会计师事务所 / 大型系统集成商 治理框架、合规文档、董事会汇报材料 实施落地。构建扫描流水线、配置 ML-BOM、部署模型签名。咨询项目起价 $500K(战略层),可扩展至 $3-10M。 需要审计就绪文档的组织
开源工具(ModelScan、PickleScan、SafeTensors) 免费的基础扫描和更安全的序列化格式 企业级编排、行为沙箱、溯源、策略强制执行 拥有强大内部安全工程能力的团队

一处无人能填补好的空白。 组织文化变革是最难的部分。没有任何工具或咨询机构能消除人为了求快而绕过治理的倾向。我们构建技术控制,但 CISO 仍然需要高管层的支持。当一名数据科学家能在 30 秒内从 Hugging Face 下载一个模型时,任何耗时 30 分钟的安全关卡都会被绕过。控制措施需要足够快,以至于合规比规避更容易。

我们为 AI 安全计划构建什么

六项能力,每一项都经过工程设计,以与您现有的安全堆栈和 CI/CD 流水线集成。

01

模型审查流水线

我们构建自动化审查机制,部署于公共模型仓库与您内部注册库之间。每个模型都会经过行为沙箱(在隔离容器中加载、监控系统调用)、多格式深度分析(pickle、PyTorch、GGUF、Keras、SafeTensors),以及使用您企业 PKI 进行的加密签名。

我们选择行为分析而非静态扫描,因为 PickleScan 的零日绕过漏洞证明了黑名单方法从根本上是失效的。静态扫描问的是"这个文件是否包含已知的恶意模式?"行为沙箱问的是"当这段代码运行时,它实际做了什么?"第二个问题才能捕获新型攻击。

02

ML-BOM 与溯源架构

集成至 CI/CD 的 CycloneDX ML-BOM 生成。每个模型都会获得一份物料清单,记录训练数据溯源、框架版本、依赖关系树和微调历史。

我们选择 CycloneDX 而非 SPDX,因为 ML-BOM 工具链更为成熟,不过我们也会为同时需要两者的组织确保 SPDX 3.0 导出。ML-BOM 不是一个合规勾选项。它是使其他所有安全控制成为可能的数据结构:你无法签名你未盘点的东西,也无法审计你无法追溯的东西。

03

影子 AI 发现

对未经授权的模型下载和 AI API 调用进行网络层检测。与您现有的 SIEM/SOAR 集成。我们绘制每一个 AI 接触点(包括影子部署)的图谱,然后构建策略强制执行,在不阻碍创新的前提下阻断风险。

目标:让您的安全团队看到 100% 的 AI 使用情况,而非当前工具所能呈现的 38%。检测范围涵盖 Hugging Face 下载、OpenAI/Anthropic/Google API 调用、通过 HTTP/S 的模型权重传输,以及通过受管端点上的进程监控发现的本地模型执行。

04

微调后安全验证

在每次微调运行之后进行自动化安全重新评估。OWASP LLM Top 10 基准测试套件、针对后门触发器的对抗性探测,以及安全对齐回归测试。

我们构建这一能力,是因为几乎没有人在微调之后重新评估安全性。上文章节中的安全退化数据已说明了问题。该验证流水线作为 CI/CD 关卡运行。一个未通过安全回归测试的模型,无论其任务表现如何,都无法被提升至生产环境。

05

智能体 AI 安全架构

面向 AI 智能体的特权分离。防止提示到 RCE 升级的确定性策略层(正是 CVE-2025-53773 中的精确攻击路径)。工具使用策略强制执行、面向高风险操作的人机协同关卡,以及运行时行为监控。

该架构能在异常智能体行为级联扩散之前将其检测出来。一个突然开始向沙箱外文件系统路径写入、调用此前从未调用过的 API,或试图进行特权升级的智能体,会被终止并标记以供审查。

06

AI 安全计划设计

面向从零开始构建该职能的 CISO。NIST AI 100-2 控制映射、EU AI Act 合规架构、董事会层面的风险量化,以及针对 AI 特有攻击的事件响应手册。

我们帮助将技术风险转化为董事会能够批准的预算论证。"我们在公共模型注册库中发现了 35.2 万个不安全问题"只是一个数据点。"我们的工程师上季度下载了 47 个未经审查的模型,其中 3 个在其序列化层中包含可执行代码,而我们当前的控制措施一个都没检测出来"才是一份预算论证。

项目如何开展

三个阶段,每个阶段都有明确的交付物,以及对预期结果的诚实说明。

第 1 阶段

发现与威胁建模

第 1-3 周

  • AI 资产盘点:编目您环境中的每一个模型、API、智能体和流水线
  • 影子 AI 排查:在所有出口点对未经授权的 AI 使用进行网络层检测
  • 威胁建模:绘制针对您部署架构和模型类型的特定攻击面
  • 对照 NIST AI 100-2 和 EU AI Act 要求进行差距分析

交付物: 附带优先级风险登记册的《AI 安全态势报告》

注意事项: 此阶段往往会揭示出比 CISO 预期多 3-5 倍的 AI 使用情况。这是正常的。影子 AI 发现是项目中最有价值、也最令人不安的部分。

第 2 阶段

架构与构建

第 4-10 周

  • 设计模型审查流水线、ML-BOM 生成和签名基础设施
  • 构建并部署至您的 CI/CD(Jenkins、GitHub Actions、GitLab CI、Azure DevOps)
  • 配置影子 AI 检测与 SIEM 集成(Splunk、Sentinel、Chronicle)
  • 将微调后安全验证作为 CI/CD 关卡实施

交付物: 集成至现有工作流程的生产就绪型安全控制

注意事项: 时间线取决于 CI/CD 的成熟度。拥有成熟 DevOps 流水线的团队部署得更快。仍在通过 USB 驱动器或共享文件夹传输模型的组织(比你想象的更常见)需要额外的基础设施工作。

第 3 阶段

运营化与移交

第 11-14 周

  • 就模型审查运营和告警分类对安全团队进行培训
  • 建立对抗性红队演练节奏(建议每季度一次,高风险系统每月一次)
  • 为模型级攻击和智能体 AI 事件构建事件响应手册
  • 附带风险量化的董事会就绪型报告模板

交付物: 配备文档化操作手册、可自我维持的 AI 安全运营

注意事项: 首次对抗性红队演练总会发现一些问题。这正是其意义所在。一个什么都没发现的红队,要么是不够努力,要么是范围划得太窄。

AI 供应链安全就绪度评估

回答八个问题,以衡量您的 AI 安全态势。不收集任何数据。所有运算都在您的浏览器中完成。

Q1您是否拥有一份生产环境中每一个 AI 模型的目录?

Q2来自公共仓库(Hugging Face、GitHub)的模型在内部使用前是否经过扫描?

Q3您是否为您的模型生成 ML-BOM?

Q4您的安全团队能否检测到未经授权的 AI API 调用?

Q5您是否在微调之后重新评估安全对齐?

Q6您的模型构件是否经过加密签名?

Q7您是否拥有针对 AI 特有攻击的事件响应手册?

Q8您的 AI 安全计划是否映射到某个框架(NIST AI RMF、EU AI Act)?

CISO 关于 AI 供应链安全常问的问题

从零开始构建一条模型审查流水线需要多长时间?

覆盖静态扫描和签名验证的基础流水线需要 4-6 周。包含 CI/CD 集成的完整行为沙箱需要 8-12 周。瓶颈很少在于扫描技术本身,而在于与您现有模型注册库(MLflow、Weights & Biases、JFrog ML)的集成,以及定义策略逻辑:什么被阻断、什么被标记、什么被隔离。我们发现,策略决策耗费的时间比工程实现还要长。

格式复杂性会增加时间。Pickle、PyTorch、GGUF、Keras 和 SafeTensors 各自需要不同的分析方法。Pickle 仍然是风险最高的格式,因为 torch.load() 在反序列化过程中执行任意 Python 代码,这正是为什么对该格式而言行为沙箱比静态扫描更重要。SafeTensors 是最安全的序列化选项,也是最易扫描的,但如今使用它的生产模型不到 20%。您的流水线需要处理所有这些格式,因为您无法控制上游模型提供方选择何种格式。

我们已经在用 Palo Alto/Wiz/JFrog 做安全防护。为什么还需要定制工作?

那些平台在各自所做的事情上都非常出色。Palo Alto 的 Protect AI 集成(通过 Prisma AIRS)让您能在现有安全堆栈内进行模型扫描。JFrog 的 MLSecOps 负责模型注册库治理。Wiz 为云可见性增添了 AI-BOM。它们不做的是:设计端到端架构、在您特定的 CI/CD 流水线中配置 ML-BOM 生成、为您的监管场景构建策略逻辑,或重新设计您的模型部署工作流程。它们是扫描工具。我们是让它们协同运作的实施团队。

许多项目始于已经拥有这些平台、但需要帮助将其运营化的组织。一种常见的情形是:安全团队六个月前购买了 Protect AI,运行了一次扫描,得到 400 条发现结果,然后就停滞了,因为没人将这些发现结果映射到修复工作流程,也没人将扫描集成到模型提升流水线中。

模型投毒的实际风险有多大?它在生产环境中发生过吗?

模型投毒的技术门槛比大多数 CISO 想象的要低。研究表明,训练语料库中只需 250 份被投毒的文档,就能为一个 130 亿参数的模型植入后门。微软于 2026 年 2 月发布了突破性的检测方法,但大多数组织尚未部署任何检测能力。微调安全退化问题更为迫近,也更为常见:Llama 3.1 8B 在提示注入抗性上,仅经历一轮微调便从 0.95 降至 0.15。这并非攻击,而是未进行安全重新评估的正常微调。

有据可查的、蓄意模型投毒的生产环境事件仍然罕见。但条件已然成熟:80%+ 的 ML 模型使用 pickle 序列化,62% 的安全团队无法识别模型的部署位置,而在 Hugging Face 上,一个名为 "baller423" 的模型被发现正在向 Kreonet 建立反向 shell。FTC 的模型吐缴先例(Weight Watchers/Kurbo,2022)意味着一个被投毒的模型可能迫使您删除模型并从头重新训练,其代价之大,远超数据泄露本身。

我们该如何应对 EU AI Act 的模型溯源要求?

EU AI Act 将于 2026 年 8 月 2 日全面适用。对于高风险 AI 系统,您需要技术文档,涵盖训练数据溯源、范围、特征和清洗方法。供应链义务要求进口商和分销商核实合格评定、技术文档和 CE 标志。实际上,这意味着为您流水线中的每个模型生成 ML-BOM、为溯源提供签名证明,以及为微调决策保留审计轨迹。

CycloneDX ML-BOM 是实施就绪度最高的标准。SPDX 3.0 于 2024 年新增了 AI/ML 配置文件,一些组织出于面向不同监管受众的需要而同时需要两种格式。我们构建文档流水线,使溯源追踪自动化,而非一项手动的合规工作。常见的错误是把这当作一次性的文档项目。每一次微调运行、每一次模型更新、每一次数据集变更,都需要生成更新后的溯源记录。如果您的 ML-BOM 是静态的,那它在几周之内就会失准。

我们能在不拖慢 AI 智能体的前提下保护它们吗?

特权分离是基础。每个智能体都会获得一份最小权限配置文件,定义它能调用哪些工具、能访问哪些 API、能触及哪些文件系统路径。这映射了应用于 AI 智能体的 Linux 能力模型。GitHub Copilot 的 RCE(CVE-2025-53773,CVSS 7.8)之所以发生,是因为 YOLO 模式赋予了智能体不受限制的系统访问权限,而代码库文档中的一处提示注入升级为完全的远程代码执行。确定性策略层能彻底阻断这条升级路径。

运行时监控增加了一条行为基线,可在不给正常操作增加延迟的情况下,检测异常的智能体行为(意外的工具调用、不寻常的 API 模式、特权升级尝试)。对高风险操作的安全检查确实存在一点点延迟成本:文件系统写入、云 API 调用、凭据访问。对于大多数企业部署而言,每个受关卡管控的操作约为 50-200ms。低风险操作(读取已批准的数据源、生成文本、调用预先批准的 API)则零延迟通过。问题在于,相比一个拥有完全系统访问权限且没有 guardrails 的智能体,在高风险调用上付出 50-200ms 是否可以接受。

AI 安全事件响应是什么样的?

AI 安全事件需要与网络入侵不同的取证。对于模型级攻击(投毒、后门),响应顺序为:将模型从生产环境中隔离、核实训练流水线的完整性、检查是否通过模型输出存在数据外泄(模型可能将窃取的数据编码进其权重中,并通过精心构造的提示将其泄露),并判断您是否需要从一个已知干净的检查点重新训练。

对于智能体 AI 事件,您还需要追踪智能体所采取的每一次工具调用和行为、核实其记忆和上下文窗口的完整性(如果上下文被存储,提示注入可能在多个会话间持续存在),并检查是否通过智能体的权限发生了横向移动。通用的 IR 流程无法涵盖模型级取证,因为构件不同。您分析的不是网络日志和内存转储,而是模型权重、训练数据溯源、微调历史和智能体行为日志。我们构建针对这些场景的专用手册,包括针对模型权重(可能多达数百 GB)的证据保全程序、训练数据的监管链文档,以及面向可能要求模型吐缴的监管机构的沟通模板。

技术研究

支撑本解决方案的技术基础,已作为详尽的白皮书发布。

您的模型正在运行。它们安全吗?

62% 的安全团队无法识别 AI 模型在其自身环境中的部署位置。

大多数组织都是在事件发生之后才发现自己的 AI 安全缺口。我们帮助您在事件发生之前找到它们。

AI 安全评估

  • ✓ 完整的 AI 资产与影子 AI 盘点
  • ✓ 模型审查流水线差距分析
  • ✓ NIST AI 100-2 与 EU AI Act 合规映射
  • ✓ 董事会就绪型风险量化报告

模型安全实施

  • ✓ 自动化模型扫描与签名流水线
  • ✓ 集成至 CI/CD 的 ML-BOM 生成
  • ✓ 影子 AI 检测与 SIEM 集成
  • ✓ 微调后安全验证