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_location="cpu", weights_only=True) # 更彻底的做法：使用只包含张量数据和 JSON 头的格式 from safetensors.torch import load_file state_dict = load_file("model.safetensors")

weights_only=True的含义是把可反序列化的类型限制在张量、基础标量和容器上，遇到未知的全局符号直接报错。参数看着简单，但它是这条链路上性价比最高的一道闸。纯张量格式的原理更干净：文件头是固定长度的一段 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 hits

pickletools.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" done

storage-cli是占位，换成你环境里实际的客户端即可，思路是一样的：把所有桶的策略拉下来做文本匹配，找出含匿名授权主体的条目。这类检查适合放进每日巡检，因为云上配置是会被"临时改一下"慢慢腐蚀的，一次性审计没有意义。同样重要的是把这类检查前移进基础设施即代码的流水线，在合并阶段就拦住显式开放匿名读的变更。

3. 资产盘点与 TRiSM 分层：看不见的模型等于已经失守

3.1 AIBOM 该记哪些字段才算能用来排查

软件物料清单大家熟悉，模型物料清单则经常被简化成一张 Excel：模型名、负责人、上线时间。这种清单在出事后毫无用处，因为你没法从"某个模型有问题"推导出"哪些应用受影响"。真正能用来排查的清单，字段设计要围绕三个问题：这东西从哪来、它依赖什么、它在哪跑。

哈希这一列最容易被省，但它恰恰是排查"模型被静默替换"的唯一手段。上游仓库的 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 架构的共性短板。所以更务实的路径是从小处切——先自动化一个边界清晰、结果可测的任务，跑一段时间拿到量化收益，再往外扩一格。反过来先立一个大而全的转型项目，通常会在半年后变成一个无法评估效果的成本中心。

从那以后我每次评估任何"自动化"方案，都会先问一句：这一步错了，多久能恢复？答不上来的，一律先做建议不做执行。希望帮到你。

本文还有配套的精品资源，点击获取