AI安全重心左移：供应链投毒、模型文件与账号接管防护

简介面向安全与风险管理领导者及AI安全、软件供应链安全从业者的Gartner 2025预测报告聚焦生成式AI落地受挫、AI代理炒作与深度伪造升温背景下的“AI动荡期”帮助读者梳理企业AI应用暴露的新攻击面与治理重点。资源包仅含1个PDF文件约215KB便于快速查阅与内部传阅。报告给出多项战略假设到2025年针对企业AI的恶意攻击中70%以上将来自软件供应链和基础设施技术栈中毒到2027年90%的网络安全AI成功实施属于任务自动化与流程增强AI代理还会加速凭证窃取与认证通信渠道攻破到2028年四成社工攻击将以深度伪造瞄准更广泛员工。文中同时提出审查应用安全实践与AI供应链组件、优先成果驱动型AI计划、重估通信渠道和凭证安全、建立AI威胁情报并针对深度伪造调优防御等建议。已有90人学习适合需要把Gartner判断转化为安全规划与防御清单的团队参考。1. 七成恶意攻击打在供应链上AI 安全的重心为什么整体左移大多数人聊 AI 安全第一反应是模型被越狱、生成内容闯祸、提示词注入。但 2025 年那份行业预测给出了一个更冷峻的结论到 2025 年底企业内针对 AI 的恶意攻击中超过 70% 落在软件供应链和基础设施技术栈的投毒上。攻击者并不急着跟模型对话他们更愿意在你下载权重、装依赖、跑 Notebook 的那一刻就完成布局。搞懂这个数字背后的攻击经济学比多买一套提示词防火墙更能决定预算花在哪里、盘点从哪开始。2. 技术栈中毒的三条路径模型文件、Notebook 与数据管道2.1 攻击者为什么总挑供应链层下手安全圈有个朴素的成本收益判断除非有非常明确的目标否则攻击者优先打基础设施和供应链。原因不复杂——射程最远、工作量最小。攻破一个被广泛引用的开源模型仓库下游所有拉取该模型的团队都成了受害者而在运行时逐笔交易去做对抗收益是线性的成本却是指数的。这条逻辑在传统软件领域已经被验证过很多轮只是 AI 让它重新活了一遍。AI 应用的开发方式天生拼装化基础模型来自公开市场或第三方权重站数据处理靠一堆 Python 库实验在 Notebook 里跑训练和推理挂在共享算力上。每一层都是外部输入每一层都默认被信任。传统应用安全那套成熟做法——依赖清单、组件分析、镜像扫描——还没来得及覆盖这些新组件安全团队手里能用的工具是有限的。更麻烦的是默认信任带来的看得见但不检查。安全团队会认真审一段业务代码却很少去核对一个.bin文件的来源会因为一个高危 CVE 紧急发版却不会因为一个 Notebook 多了两行 shell 命令而拦下提交。有做开源模型扫描的厂商反馈抽样检查里约 1% 的开源模型被植入恶意代码另有数千个被污染的 Notebook 出现在客户环境里。1% 听起来不高但放在随便下载、直接加载的使用习惯上这个比例意味着几乎每个模型仓库都可能有颗雷。2.2 一个权重文件为什么能执行代码这是整条链路里最反直觉的一环。很多人以为模型文件是纯数据加载它最多是读文件不会有副作用。事实是主流格式里有一大类基于 Python 的 pickle 序列化协议而 pickle 在设计上就允许反序列化即执行。import pickle import os class Payload: def __reduce__(self): # __reduce__ 返回 (可调用对象, 参数元组) # pickle.loads 在重建对象时会无条件调用这个可调用对象 return (os.system, (id /tmp/probe.txt,)) blob pickle.dumps(Payload()) open(model.pkl, wb).write(blob)这段代码不是完整攻击它只是把机制摊开__reduce__是 pickle 协议规定的钩子序列化时把怎么重建这个对象记进字节流反序列化时解析器照着指令干活遇到REDUCE指令就把栈上的可调用对象和参数取出来直接调用。整个过程没有任何沙箱也不区分数据和指令。基于 pickle 的张量加载函数在旧版本里默认走的就是这条路径攻击者只要把这段字节塞进一个看起来正常的权重文件前面保留合法的张量结构让静态扫描器以为一切正常后面挂上载荷即可。常见的防御思路是两条能不用 pickle 就不用用只存纯张量的格式必须用的时候显式关掉对象重建。import torch # 显式声明只加载张量禁止反序列化任意 Python 对象 state_dict torch.load(model.bin, map_locationcpu, weights_onlyTrue) # 更彻底的做法使用只包含张量数据和 JSON 头的格式 from safetensors.torch import load_file state_dict load_file(model.safetensors)weights_onlyTrue的含义是把可反序列化的类型限制在张量、基础标量和容器上遇到未知的全局符号直接报错。参数看着简单但它是这条链路上性价比最高的一道闸。纯张量格式的原理更干净文件头是固定长度的一段 JSON记录每个张量的偏移和形状正文全是裸字节解析器不会去解析任何可调用对象。代价是它无法保存优化器状态之外的任意 Python 结构迁移时得改代码。注意仅仅改扩展名没有意义。判断一个文件是否可执行看的是内容格式和加载函数的参数不是.bin还是.safetensors。如果要批量排查存量模型可以在入库前做一次 opcode 级扫描import pickletools # 与重建对象相关的关键指令REDUCE 是真正的执行点 SUSPICIOUS {REDUCE, INST, OBJ, NEWOBJ, NEWOBJ_EX, BUILD} def scan_pickle(path): hits [] with open(path, rb) as f: data f.read() try: for op, arg, pos in pickletools.genops(data): if op.name in SUSPICIOUS: hits.append({offset: pos, opcode: op.name, arg: arg}) except Exception as exc: hits.append({offset: -1, opcode: PARSE_ERROR, arg: str(exc)}) return hitspickletools.genops把字节流逐条翻译成指令offset是字节偏移方便定位opcode是指令名。要注意正常权重文件里也会出现全局符号引用比如张量类型所以不能把GLOBAL一律判黑否则误报会淹没你真正该盯的是REDUCE这类取出可调用对象并调用的指令。生产上更稳的做法是维护一份白名单只允许已知的张量重建符号通过。2.3 Notebook 与数据管道被当成配置的攻击面Notebook 是 AI 团队最不当回事的资产。它本质是一段 JSON单元格里有代码、有输出、有执行计数还允许!前缀直接调 shell、允许内嵌 HTML。这意味着两件事第一一个被别人改过的 Notebook 可以在你只是打开看看时执行任意命令第二输出里可以藏脚本导出成 HTML 分享时就成了钓鱼页面。它还有一个隐蔽特性——JSON 结构让 diff 变得难读代码评审时人很自然地滑过去改一行依赖版本、加一行!pip install都不容易被发现。数据管道的问题则是另一种形态。多数事故不是高明的攻击而是默认配置加侥幸心理对象存储桶建好就是可读的、连接串硬编码在脚本里、调试日志把完整凭据打了出来、临时开放的访问策略上线忘了收。攻击者在这类环境里的收益比逐笔交易对抗大得多——一次配置失误流出去的是整批训练数据或者整张特征表。有报告提到攻击者认为攻击数据管道比攻击单次运行时事务更划算原因就是数据管道通常缺乏等同于生产接口的监控和鉴权。# 用对象存储命令行客户端导出每个桶的访问策略筛出对匿名用户开放的桶 storage-cli list-buckets --format text | while read -r bucket; do policy$(storage-cli get-bucket-policy --bucket $bucket 2/dev/null) echo $policy | grep -q AllUsers echo ANONYMOUS-READABLE: $bucket donestorage-cli是占位换成你环境里实际的客户端即可思路是一样的把所有桶的策略拉下来做文本匹配找出含匿名授权主体的条目。这类检查适合放进每日巡检因为云上配置是会被临时改一下慢慢腐蚀的一次性审计没有意义。同样重要的是把这类检查前移进基础设施即代码的流水线在合并阶段就拦住显式开放匿名读的变更。3. 资产盘点与 TRiSM 分层看不见的模型等于已经失守3.1 AIBOM 该记哪些字段才算能用来排查软件物料清单大家熟悉模型物料清单则经常被简化成一张 Excel模型名、负责人、上线时间。这种清单在出事后毫无用处因为你没法从某个模型有问题推导出哪些应用受影响。真正能用来排查的清单字段设计要围绕三个问题这东西从哪来、它依赖什么、它在哪跑。字段记录内容出事时用来回答什么模型标识与哈希名称、版本、文件 SHA-256同一个模型是否被替换过来源与获取方式仓库地址、拉取时间、签名校验结果上游是否被投毒序列化格式pickle 系 / 纯张量 / 其他是否需要做反序列化风险排查依赖与运行时框架版本、Python 库清单某个 CVE 影响了哪些服务数据血缘训练与微调数据来源、授权状态数据外流或合规追溯部署位置推理端点、算力环境、暴露面爆炸半径有多大哈希这一列最容易被省但它恰恰是排查模型被静默替换的唯一手段。上游仓库的 tag 可以移动文件可以被覆盖只有你自己算过的哈希不会骗人。依赖列也不是照抄requirements.txt而要记录实际加载的版本——AI 项目里pip install临时升级导致的版本漂移非常普遍清单和现实经常对不上。3.2 从运行时防护扩展到四个面信任、风险与安全管理这套框架落到工程上其实就是把防护面从运行时扩成四层。绝大多数团队在运行时这一层做得不错接口鉴权、输入过滤、输出审计、限流。但另外三层往往是空的。模型层管的是模型本身的可信度来源校验、格式检查、完整性哈希、上线前的行为基线测试。数据层管的是进出的数据训练数据授权、数据管道的访问控制、特征表的读写权限、脱敏策略。基础设施层管的是承载环境算力隔离、机密计算、镜像与依赖的完整性、网络分段。这四层不是并列关系而是有优先级的。运行时的攻击需要实时对抗成本高供应链和基础设施的攻击是一次性投入、长期收益所以攻击者正在往那边迁移防护也必须跟着左移。一个可操作的判断标准是如果一个攻击者拿到了你的模型仓库读权限你多久能知道哪些应用被污染了如果答案是不知道那运行时防护做得再细也只是在守一扇没锁的后门旁边的窗户。落地时不必追求一次性建全。常见路径是先做发现与清点把散落在个人目录、共享盘、临时算力上的模型和 Notebook 收进清单再把已有的应用安全实践平移过来比如依赖扫描、镜像扫描、密钥扫描先覆盖能覆盖的最后才是引入针对 AI 组件的专门检测比如反序列化格式扫描、Notebook 静态分析、模型行为基线。顺序反过来做通常会得到一堆扫描报告和一个没人维护的清单。4. 账号接管的加速带AI Agent 如何把利用窗口压掉一半4.1 ATO 杀伤链上正在被自动化的环节账号接管是一条很老的链路获取凭据、验证可用、绕过二次验证、接管会话、变现。老归老它一直是最高频的入侵入口之一因为凭据的来源太多了——数据泄露、钓鱼、恶意软件、内部复用。攻击者拿到一批账号密码后用自动化脚本在多个服务上批量尝试赌的就是复用。报告给出的判断是到 2027 年AI Agent 会把这条链路上更多环节自动化账号暴露后的利用时间缩短一半。这 50% 不是凭空的数字拆开看每一段都能对上。凭据获取这一段生成钓鱼话术、批量定制诱导内容本来就是语言模型的强项成本被压到接近零。绕过二次验证这一段语音克隆让打个电话确认一下这个传统兜底动作失效——几分钟的公开音频样本就足够合成出可用的声音。会话接管这一段中间人代理可以实时把用户的一次性验证码中转给攻击者用户那边看到的是正常的登录页面验证码也确实收到了只是同时被用掉了。推送轰炸则是另一个思路不断弹验证请求赌用户点烦了随手同意。这几段串起来意味着人肉判断在链路里的权重越来越低。以前防御方还能靠攻击者忙不过来这个事实争取时间窗口现在窗口在收窄。4.2 认证通道对比为什么换了强认证还不够通道抗钓鱼能力主要失效方式静态密码无泄露、复用、撞库短信/邮件验证码弱实时中转、通道劫持推送确认中轰炸疲劳、误点本地生成的一次性码中实时中转、种子泄露设备绑定的公钥凭据强设备丢失、注册流程被绕过抗钓鱼能力最强的是基于公钥、与源站域名绑定的那类凭据因为私钥永远不会离开设备中间人拿到的只是一个无法在其他域名复用的签名。问题在于覆盖率管理工具和大型消费服务支持得快企业自建系统和终端用户的迁移却很慢遗留密码在可预见的未来还会存在。所以现实的策略不是等强认证普及而是在过渡期承认密码还在然后针对密码还在这个前提做补偿控制异常登录的行为基线、 Impossible travel 类的地理矛盾检测、敏感操作的二次确认、会话时长的收缩。一个常被忽略的点是通信通道本身。账号找回、验证码下发、人工客服核身这些流程走的都是通信渠道而深度伪造正好打在这里。当伪造语音的成本低到可以批量拨打靠听声音像不像来核身的流程就等于没有。可行的替代是把核身从识别对方是谁改成验证一个只有本人知道的秘密——预设口令、回拨到已登记号码、要求走应用内确认而不是电话。4.3 深度伪造目标从高管下沉到全员过去谈社会工程画面是冒充老板给财务发指令。报告的预测是到 2028 年四成社会工程攻击会借助深度伪造等技术目标不只是高管而是更广泛的员工群体。逻辑很直白高管的通信渠道被重点加固了普通员工没有而普通员工手里的权限往往足够打开第一道门。这类攻击的防御重点不在识别假视频因为识别永远在追赶生成。更靠谱的是流程层面的硬约束任何涉及资金、权限变更、数据导出的请求都必须走一条独立于请求来源的验证路径。请求本身可以伪造流程不能。同时要把可疑即上报的摩擦降到足够低让员工在不确定时敢停下来问一句而不是怕麻烦硬着头皮办了。5. 避坑与排查五条踩坑记录5.1 依赖扫描全绿模型目录里躺着来源不明的权重现象CI 里的依赖漏洞扫描一直是绿的镜像扫描也过但模型目录里有个几百兆的权重文件没人说得清从哪来、谁什么时候放进去的。原因传统组件分析解析的是包管理器清单——requirements.txt、package.json、锁文件。模型文件不是包不在任何清单里扫描器自然不会去看它。团队把扫过依赖等同于扫过所有第三方内容这个等号是错的。解决把模型和 Notebook 当成一等资产纳入清单记录来源、哈希、格式在流水线里加一道针对序列化格式的检查用前面那段 opcode 扫描跑一遍把REDUCE类指令和未知全局符号列出来人工过一遍。对没有来源记录的存量模型宁可重新从可信来源拉一次也别抱着应该没问题的心态继续用。5.2 Notebook 输出入库diff 永远看不完现象一个 Notebook 在生产环境被改过三次代码评审记录里只有更新参数实际改动包括依赖版本、数据路径和一段额外的下载逻辑。没人发现因为 diff 太长。原因Notebook 是 JSON单元格输出、执行计数、图片的 base64 编码全都混在文件里一次运行就能产生几千行差异。评审者的注意力被噪声吃掉真正的代码改动淹没在里面。解决三件事一起做——入库前清空输出和执行计数把 Notebook 转成纯脚本再提交评审禁止在 Notebook 里直接执行未固定版本的安装命令。这些都能用工具链自动化不需要靠自觉。约束加进去的头两周会有人抱怨之后就变成默认习惯。5.3 数据管道默认配置直接上线现象测试环境跑通的数据管道原样上了生产几周后做例行检查发现某个中间结果桶对匿名访问开放里面是带用户标识的特征数据。原因默认配置是为了能跑通设计的不是为安全设计的。开发阶段图省事直接用了默认策略上线时没人回头审一遍而云上配置会随着临时需求不断被放宽且没有任何机制提醒。解决把访问策略写进基础设施即代码合并前强制检查加一条定期巡检扫出显式开放匿名访问的资源并告警数据管道的每个节点显式声明输入输出和权限边界不要让能连通成为唯一的验收标准。5.4 MFA 全覆盖就以为 ATO 结案现象二次验证覆盖率做到 100% 之后仍然有账号被接管日志显示验证是通过的。原因验证通过不等于验证有效。推送轰炸靠的是用户疲劳一次性验证码可以实时中转语音核身可以被合成声音绕过。覆盖率是个部署指标不是防护效果指标。解决把推送改成需要匹配数字的确认方式缩短验证请求的有效期对高频请求做限流把敏感操作的核身方式换成设备绑定的强凭据建立登录行为基线对地理矛盾、设备突变、异常时段做加权评分而不是只看验证是否通过。5.5 让 Agent 直接执行处置动作现象给告警处置配了个自动化 Agent上线第一周就自动封禁了一个内部服务账号还改了一次防火墙策略事后证明是误报。原因模型和 Agent 的误报率在开放环境里不会归零而处置动作的容错度极低。检测环节错了只是多一条噪声处置环节错了就是业务中断。把这两件事放在同一个自动化层级上是把风险放大了。解决按错误成本分级。只读的分析、归并、优先级排序可以全自动涉及封禁、改配置、改权限的动作先只生成建议由人确认执行确实要自动执行的加影响范围上限比如一次只处理一个对象、加回滚预案、加抽样人工复核。这个配比不是一次定死的得靠一段时间的数据慢慢调。6. 自治与控制的配比为什么九成 AI 安全落地停在任务增强报告里有个容易被忽略的判断到 2027 年网络安全领域成功的 AI 落地中九成是战术级的——任务自动化和流程增强而不是角色替代。同时另一组数据是只有约一成出头的安全负责人表示已经拿到可衡量的成果。这两件事放在一起看说明问题不在技术不行而在期望值放错了位置。任务增强和角色替代的差别本质是错误成本能不能被吸收。告警归并做错了多一条噪声漏洞优先级排序做错了晚修三天这两类工作对错误的容忍度高模型能力刚好够用收益立刻可见。而自主运营整个安全运营中心这种目标容错度接近零一个误判就是业务中断于是无论供应商怎么宣传实际落地都会退回到有人监督的半自动模式。我一般会这么理解这个取舍自治程度应该跟错了之后能不能吃后悔药挂钩。可逆的动作可以激进不可逆的动作必须留人。具体到工程上就是给每个用例单独标定三个参数——自动执行的影响半径、人工抽检的比例、回滚的时间成本。抽检比例不是形式主义它是你唯一能持续验证模型判断还准不准的手段一旦停了系统就变成黑匣子。还有一个现实约束编排多步骤工作流的技术成熟度仍然偏低。单步能力强、多步串起来就容易发散这是当前 Agent 架构的共性短板。所以更务实的路径是从小处切——先自动化一个边界清晰、结果可测的任务跑一段时间拿到量化收益再往外扩一格。反过来先立一个大而全的转型项目通常会在半年后变成一个无法评估效果的成本中心。从那以后我每次评估任何自动化方案都会先问一句这一步错了多久能恢复答不上来的一律先做建议不做执行。希望帮到你。本文还有配套的精品资源点击获取