简介这份PDF资料是Gartner于2025年2月发布的预测报告面向安全与风险管理领导者、企业安全架构师及AI治理从业者聚焦AI驱动下的网络安全新挑战。报告指出到2025年软件供应链与基础设施技术栈中毒将占企业AI相关恶意攻击的70%以上并剖析早期GenAI落地受挫、AI代理漂洗、深度伪造与自动化账户接管等风险同时给出审查应用安全实践、优先成果驱动AI计划、预判凭证攻击等可操作建议。资源包共1个PDF文件约215KB篇幅精炼便于快速通读与团队分享。目前已有90人学习。读者可从中获取Gartner对2025—2028年的战略规划假设、AI软件供应链漏洞清单思路及安全团队应对自动化攻击的防御要点适合用于年度安全规划、AI治理议题讨论与威胁建模参考。1. 70% 恶意攻击来自供应链AI 安全的主战场为什么不在模型本身大多数人谈 AI 安全第一反应是「模型会不会被越狱」「提示词注入怎么防」。但一份 2025 年的行业预测给出了一个反直觉的结论到 2025 年底针对企业内 AI 的恶意攻击中超过 70% 来自软件供应链和基础设施技术栈的投毒而不是模型推理层。换句话说攻击者根本没打算跟你的对齐算法硬碰硬他们盯上的是你pip install的那一行、Jupyter Notebook 里那段没人审的单元格、以及数据管道上那个默认开放的配置项。这个数字值得每一个做 AI 应用的开发者认真对待因为它意味着你花大力气加固的模型服务可能从一开始就建在一条被污染的流水线上。搞懂这条流水线是怎么被下毒的、为什么传统扫描工具接不住比追任何一个新框架都更值。2. 供应链投毒为什么攻击者偏爱数据管道而不是模型权重2.1 攻击面的迁移从运行时事务到构建时组件传统应用安全的假设是「攻击发生在运行时」——SQL 注入、越界访问、反序列化都是请求打进来那一刻的事。所以防御重心放在 WAF、RASP、运行时监控上。但 AI 应用的形态变了它的核心资产不是一段处理请求的代码而是一整条从数据采集、清洗、特征工程到模型训练、部署的管道。这条管道上有大量第三方组件——开源模型、Python 库、Notebook、预训练权重、数据标注工具。攻击者算的是一笔经济账。打一个运行时事务收益是单次请求的数据打一条数据管道收益是管道里流过的所有数据而且只需要成功一次。这就是预测里那句「攻击数据管道比逐个攻击运行时事务更有成效」的底层逻辑。常见的实现思路是在开源模型的分发环节植入恶意代码或者在 Notebook 的依赖里塞一个带后门的包等企业拉取时自动执行。这类攻击不需要攻破你的边界它借的是你自己「信任并拉取」的动作。从机制上看这利用了软件供应链的信任传递特性。你信任transformers这个包于是你信任它依赖的tokenizers于是你信任tokenizers依赖的某个底层库。攻击者只需要在链条末端污染一个环节整条链上的信任就全部被劫持。AI 场景的特殊之处在于这条链比传统 Web 应用长得多、杂得多而且很多环节根本没有纳入安全团队的资产清单。2.2 为什么传统应用安全工具接不住 AI 组件这里有个血泪经验值得说透很多团队以为现有的 SCA软件成分分析和漏洞扫描能覆盖 AI 组件实际跑一遍才发现是黑匣子。原因有三层。第一层是识别问题。传统 SCA 靠包管理器清单requirements.txt、package-lock.json来枚举依赖但 AI 项目里大量组件不走标准包管理——直接下载的.pt、.safetensors权重文件从模型市场拉的开源模型散落在 Notebook 里的内联代码这些在清单里根本看不见。资产都盘不清扫描自然无从谈起。第二层是格式问题。模型权重是二进制大文件传统扫描器要么跳过、要么误报。而投毒恰恰可能藏在权重的序列化格式里——某些序列化格式支持在加载时执行任意代码这就是一个天然的代码执行入口。第三层是语义问题。就算扫到了某个 Python 库有漏洞传统工具也很难判断这个漏洞在 AI 管道里是否真的可达。一个只在训练脚本里用到的反序列化函数和一个在推理服务里暴露的函数风险等级完全不同但工具给的是同一个 CVSS 分数。下面这段伪代码展示了典型的资产发现逻辑能看出为什么「盘清 AI 组件」本身就是个工程问题# 扫描 AI 项目的组件清单覆盖标准依赖 非标准资产 import json from pathlib import Path def discover_ai_assets(project_root): assets {packages: [], models: [], notebooks: []} # 1. 标准包依赖从 requirements / lock 文件解析 for req in Path(project_root).rglob(requirements*.txt): for line in req.read_text().splitlines(): if line and not line.startswith(#): assets[packages].append(line.split()[0].strip()) # 2. 非标准资产模型权重文件按扩展名枚举 model_exts {.pt, .pth, .safetensors, .onnx, .pkl} for f in Path(project_root).rglob(*): if f.suffix in model_exts: assets[models].append(str(f)) # 3. Notebook单独归类因为内联代码不走包管理 for nb in Path(project_root).rglob(*.ipynb): assets[notebooks].append(str(nb)) return assets if __name__ __main__: result discover_ai_assets(./my-ai-project) print(json.dumps(result, indent2))这段代码的关键不在复杂度而在它揭示的事实packages只是资产的一部分models和notebooks才是 AI 项目里最容易被漏掉、也最容易被投毒的部分。model_exts里特意包含.pkl是因为 pickle 格式在反序列化时可以执行任意代码这是供应链投毒的经典载体。实际落地时这个发现函数应该作为 CI 流水线的第一步产出的清单再喂给后续的漏洞评估和签名校验。参数上project_root要覆盖所有代码仓库而不只是主仓库否则子模块里的资产会漏掉。2.3 分层防御TRiSM 栈怎么落到工程上预测里反复提到 TRiSM信任、风险与安全管理分层防御落到工程上不是买一个产品而是把防护点铺到管道的每一层。我一般会这么理解这个栈最底层是基础设施计算、存储、网络往上是数据管道再往上是模型与组件最上层是应用与交互。每一层都要有独立的发现、评估、阻断能力。基础设施层的关键手段是机密计算和工作负载加固——让数据在内存里也是加密的即使宿主机被攻破也拿不到明文。数据管道层要做深度检查监控数据流向防止敏感数据被悄悄外泄到外部服务器。模型与组件层就是前面说的资产发现加签名校验。应用层才是大家最熟悉的提示词防护、输出过滤。这个分层思路的价值在于它承认了单点防御必然失效。供应链投毒可能发生在任何一层只有每层都有独立的检测点才能把「一次投毒成功」的概率压下去。常见的踩坑是只做最上层结果底层组件被污染了上层防护再严也是给一个已经被控制的系统做门禁。3. AI 代理与账户接管自动化攻击链是怎么把利用时间砍半的3.1 ATO 杀伤链的自动化从社工到撞库的端到端账户接管ATO是个老问题但 AI 代理把它从「手工活」变成了「流水线」。传统 ATO 杀伤链大致是拿到泄露凭证 → 社工补充信息 → 撞库尝试 → 绕过 MFA → 登录成功。每一步都需要人速度慢、成本高、容易被风控拦截。AI 代理介入后这条链上多个环节被自动化。深度伪造语音可以做社工电话自动化的撞库工具可以跨大量服务并发尝试而针对 MFA 的攻击——比如拦截短信或邮件里的一次性验证码、或者用推送轰炸逼用户点确认——也能被编排进同一个流程。预测给出的量化结论是到 2027 年AI 代理会把利用账户暴露的时间缩短 50%。这个 50% 不是拍脑袋。它的机制是「并行化 去人工等待」。人工攻击时社工电话打完要等对方反应撞库失败要手动换目标每一步都有延迟。代理可以同时跑几十条攻击线哪条先成功就走哪条。时间被压缩的本质是把串行的等待变成了并行的竞速。3.2 为什么 FIDO2 推了这么久还没普及按理说FIDO2 通行密钥能从根本上解决凭证被盗和 MFA 绕过的问题——它基于公钥密码学私钥不出设备没有可被拦截的一次性验证码也不怕推送轰炸。但预测里明确说大多数终端用户组织和用户本身的采用进展缓慢密码这类遗留凭证在可预见的未来还会继续存在。原因不是技术不行是迁移成本和组织惯性。存量系统要改造认证流程用户要重新注册凭证跨设备的体验要打磨客服要处理大量「我换了手机登不上」的工单。这些摩擦让很多组织选择「先维持现状」。而攻击者恰恰吃准了这个窗口——只要还有大量密码在用ATO 就永远有入口。从防御设计上看这意味着不能把宝全押在「等大家都上 FIDO2」上。过渡期的策略是分层高价值账户强制 FIDO2普通账户至少上抗钓鱼的 MFA同时对异常登录行为做基于风险的实时判定。AI 代理攻击的特征是「快」和「广」风控的响应也必须是实时的不能靠事后审计。3.3 半自动化工作流里的人工校验点预测里有一条建议很实在在半自动化工作流里保留定期人工校验测试阶段做抽样验证上线后继续维持。这条建议背后的机制是「容错边界」——AI 代理适合处理容错率高、失败可回滚的任务比如事件分析、漏洞优先级排序但涉及凭证、权限、资金的操作必须有人工确认的闸门。常见的实现思路是在代理的执行链里插入「确认节点」代理完成信息收集和方案生成但在执行关键动作前暂停等人确认。这个节点的位置很讲究——放太前人工负担重放太后损失已经造成。我一般会把它放在「不可逆操作」之前比如删除、转账、改权限。参数上确认超时要有默认拒绝策略不能默认放行。4. 深度伪造与 AI 威胁情报为什么不能靠恐慌来防御4.1 深度伪造的攻击面扩展从高管到全员预测里有个容易被忽略的转折到 2028 年40% 的社工攻击不再只针对高管而是扩展到更广泛的员工群体用深度伪造和其他「伪造现实」技术。这个变化的机制是成本下降。过去伪造一段高管语音需要专业团队现在工具化之后伪造一个普通员工的语音或视频成本极低攻击者可以广撒网。对防御方来说这意味着「重点保护高管」的策略失效了。普通员工同样会接到伪造的上级指令、伪造的供应商付款请求。防御的重心要从「保护特定人」转向「保护通信信道」——验证请求来源的真实性而不是假设某个身份天然可信。4.2 威胁情报的调优盯着观测到的有害攻击而不是想象中的预测给的建议里有一句很关键保持 AI 威胁情报能力把防御调优到「观测到的、有害的」深度伪造攻击上而不是被潜在威胁牵着走。这句话点出了一个常见翻车场景团队看到深度伪造的新闻就慌了仓促上马一堆检测工具结果误报率高、运维成本大真正该防的攻击反而没防住。正确的做法是先建立观测基线——你的组织实际收到过哪些伪造攻击是语音还是视频是冒充内部还是外部攻击成功的路径是什么有了这个基线再针对性地上检测和流程控制。威胁情报的价值不在于「知道有这种攻击」而在于「知道这种攻击在我们这里长什么样」。提示深度伪造检测工具本身也有误报和对抗样本问题不要把它当成唯一防线。流程上的「回拨确认」「多信道验证」往往比检测模型更可靠。5. 避坑与排查AI 安全落地时最容易翻车的几个点5.1 现象扫描报告说「无高危漏洞」但模型市场拉下来的权重被执行了原因传统 SCA 只扫包依赖不扫模型权重文件权重里的恶意序列化载荷完全在视野外。解决把模型文件纳入资产清单加载前做格式校验和签名验证禁用不安全的反序列化路径。5.2 现象上了 AI 代理做漏洞优先级排序结果排出来的顺序和实际风险对不上原因代理的输入里缺少资产上下文——它不知道某个漏洞所在的组件是否真的在推理路径上可达。解决给代理喂资产可达性数据并在排序结果上保留人工抽检别让代理直接驱动修复排期。5.3 现象MFA 都开了还是被 ATO 攻破原因用的是可被拦截的带外验证码或推送确认攻击者用代理批量触发推送轰炸或拦截验证码。解决高价值账户切到抗钓鱼的 FIDO2过渡期加基于风险的登录判定对异常并发登录做实时阻断。5.4 现象深度伪造检测工具上线后误报不断业务方要求关掉原因检测阈值按通用数据集调没适配本组织的通信特征且缺少人工复核流程。解决先用观测数据建基线阈值按实际攻击样本调检测结果先进人工复核队列再决定是否阻断。5.5 现象AI 项目资产盘不清安全团队不知道要保护什么原因AI 组件散落在多个仓库、Notebook、模型市场没有统一的发现流程。解决把资产发现做成 CI 的第一步覆盖标准依赖、模型文件、Notebook 三类产出清单后再接漏洞评估和治理工具。6. 设计取舍为什么「战术级 AI」比「全自动安全」更值得投把前面几条线收在一起会发现一个共同的取舍AI 在安全里的成功短期内大概率是战术级的——任务自动化和流程增强而不是角色替代。预测给的数字是到 2027 年 90% 的成功实现属于这一类。这个判断背后是容错率的现实。安全运营对误报和业务中断的容忍度极低。一个全自动的响应代理如果误封了一个关键服务损失可能比它挡住的攻击还大。所以真正能落地的是那些「失败可回滚、收益可观测」的环节事件分析的初筛、漏洞优先级的排序、日志的归并。这些任务即使 AI 出错人工也能兜住。而「全自动处置」这种高风险动作在可预见的未来还是得留人工闸门。这个取舍也解释了为什么早期 GenAI 实验会让一些团队失望——期望值被拉到了「替代分析师」实际交付的是「帮分析师省掉重复劳动」。期望和现实的错位比技术本身的局限更伤人。我见过不少团队因为一次不成功的 PoC 就否定整个方向这其实是把战术级工具当战略级方案来验收了。验证一个 AI 安全方案是否值得投我一般会看三个指标它省掉的人工工时是否可量化、它的错误是否可回滚、它的收益是否在两周内能观测到。三个都满足才值得扩大范围。这套验证方法比任何厂商的演示都可靠因为它逼你把「听起来很厉害」翻译成「到底省了什么、错了怎么办、多久见效」。从那以后我每次评估 AI 安全工具都强制走一遍「可量化、可回滚、可观测」这三问答不上来的先放一放。希望帮到你。本文还有配套的精品资源点击获取