简介这份PDF资料源自Gartner于2025年2月发布的预测报告面向安全与风险管理负责人、企业安全架构师及AI治理从业者聚焦AI驱动下网络安全面临的新挑战。内容围绕AI动荡期展开涵盖应用安全程序弱点、AI管道软件组件库存不足带来的新攻击面、早期生成式AI实验受挫对安全团队信心的影响以及深度伪造、伪造语音和规模化诈骗内容等威胁。报告还给出战略规划假设到2025年软件供应链与基础设施技术栈中毒将占企业AI恶意攻击的70%以上到2027年90%的成功AI安全落地为战术性任务自动化到2028年40%的社会工程攻击将借助深度伪造瞄准更广泛员工群体。资源包为1个PDF文件大小约215KB结构紧凑便于快速查阅。已有89人学习适合需要把握AI安全趋势、制定防御策略并优化AI软件供应链安全实践的专业人士参考。1. 当 70% 的恶意攻击来自供应链这份 Gartner 预测到底在说什么如果你正在负责企业 AI 项目的安全落地大概率已经感受到一种割裂业务侧催着上模型、上 Agent、上自动化安全侧却连 AI 管道里到底引了哪些开源组件都说不清楚。Gartner 这份 2025 年 2 月发布的预测报告核心判断就一句话——到 2025 年底针对企业 AI 的恶意攻击中超过 70% 会来自软件供应链和基础设施技术栈的投毒。不是模型算法被攻破不是推理接口被打穿而是你从开源社区拉下来的那个模型权重、那个 Jupyter Notebook、那个 Python 依赖包本身就是攻击载体。这份报告适合三类人正在做 AI 应用安全评审的安全工程师、负责 AI 平台建设的架构师、以及需要向管理层解释“为什么 AI 安全预算不能只买一个防火墙”的安全负责人。它不提供具体工具的操作手册但给出了明确的战略假设和行动框架这正是做安全规划时最需要的“锚点”。2. 供应链投毒为什么成了 AI 安全的主战场从攻击面变化说起2.1 传统应用安全工具为什么覆盖不了 AI 组件Gartner 在报告中点出了一个关键矛盾大多数企业的应用安全工具链在设计之初根本没有考虑 AI 实体。SAST 扫的是你写的代码DAST 测的是你的 Web 接口SCA 查的是 Maven、npm 里的依赖——但 AI 管道里的东西呢模型权重文件、Hugging Face 上拉下来的预训练模型、数据科学 Notebook 里的 pickle 序列化对象、ML 管道的配置文件这些都不在传统工具的扫描范围内。常见做法是安全团队以为买了 SCA 工具就覆盖了供应链安全结果发现 SCA 根本不认识.pt、.h5、.pkl这些格式更不会去检查模型文件里是否嵌入了恶意代码。Gartner 引用的客户反馈显示专业 AI 安全厂商在客户现场扫描开源模型时发现高达 1% 的开源模型被植入了恶意软件数千个被感染的数据科学 Notebook 被找到。这个比例放在传统软件供应链里可能不算惊人但考虑到 AI 模型往往被直接加载执行、Notebook 往往以高权限运行实际风险被显著放大。攻击者的逻辑很直接与其针对某一个具体目标做定制化攻击不如在供应链上游投毒一次感染、广泛传播。开源模型市场、Notebook 分享平台、Python 包索引都是“投入产出比”极高的攻击入口。而且AI 管道的用户配置错误——比如把数据管道指向了外部服务器、把训练数据暴露在公开存储桶里——让攻击者可以绕过运行时防护直接从数据流里窃取敏感信息。2.2 从 TRiSM 框架到落地AI 资产盘点怎么做Gartner 建议用 TRiSMTrust, Risk and Security Management框架来管理 AI 治理、信任、风险和安全。这个框架本身不复杂难的是落地第一步你得先知道自己有哪些 AI 资产。我一般会建议按这个顺序做盘点第一步梳理 AI 项目清单。不要只问安全团队要拉上业务侧和研发侧一起过。很多 AI 项目是业务部门自己用低代码平台搭的安全团队根本不知道存在。盘点维度包括项目名称、负责人、使用的模型来源自研/开源/商业 API、训练数据来源、部署环境云/本地/混合、对外暴露的接口。第二步扫描 AI 管道组件。对每个 AI 项目列出其依赖的软件组件Python 包及其版本、模型文件及其哈希、Notebook 文件及其来源、ML 管道配置文件。这一步可以借助软件成分分析工具但需要确认工具是否支持 AI 相关格式。第三步评估现有安全工具的覆盖缺口。拿你的 SAST、DAST、SCA、容器安全工具逐一测试它们对 AI 组件的检测能力。比如SCA 能不能识别requirements.txt里的 AI 相关包容器安全工具能不能扫描模型文件如果答案是否定的就需要引入专门的 AI 安全扫描工具。下面是一个简化的 AI 资产盘点脚本示例用 Python 扫描项目目录提取 AI 相关组件信息import os import json import hashlib # 定义需要关注的 AI 组件文件模式 AI_PATTERNS { model: [.pt, .pth, .h5, .onnx, .pkl, .joblib], notebook: [.ipynb], config: [requirements.txt, environment.yml, Pipfile, pyproject.toml], pipeline: [*.yaml, *.yml, Dockerfile] } def scan_ai_assets(root_dir): 扫描目录识别 AI 相关组件并计算哈希 assets [] for dirpath, _, filenames in os.walk(root_dir): for fname in filenames: ext os.path.splitext(fname)[1].lower() # 判断文件类型 asset_type None for atype, patterns in AI_PATTERNS.items(): if ext in patterns or fname in patterns: asset_type atype break if asset_type: fpath os.path.join(dirpath, fname) # 计算文件哈希用于后续完整性校验 file_hash hashlib.sha256() try: with open(fpath, rb) as f: for chunk in iter(lambda: f.read(8192), b): file_hash.update(chunk) assets.append({ path: fpath, type: asset_type, size: os.path.getsize(fpath), sha256: file_hash.hexdigest() }) except (IOError, OSError) as e: print(f无法读取 {fpath}: {e}) return assets if __name__ __main__: # 替换为你的 AI 项目根目录 results scan_ai_assets(./ai_projects) # 输出为 JSON方便后续导入资产管理平台 print(json.dumps(results, indent2, ensure_asciiFalse))这段脚本的逻辑很直白遍历指定目录按扩展名和文件名识别模型文件、Notebook、依赖清单和管道配置然后计算每个文件的 SHA256 哈希。哈希值的作用是建立基线——后续如果模型文件被篡改哈希会变化你就能发现。参数方面AI_PATTERNS字典可以根据你的实际技术栈调整比如如果你用 TensorFlow.pb文件也要加进去如果你用 R 语言做数据科学.rds和.Rmd也要纳入。注意这个脚本只做资产发现和哈希基线不做恶意代码检测。真正的模型安全扫描需要专门的工具比如检查 pickle 文件是否包含恶意__reduce__调用、检查模型权重是否被植入后门触发器。2.3 软件成分分析与漏洞评估在 AI 场景下的适配传统 SCA 工具的工作方式是解析依赖清单文件提取组件名称和版本然后与漏洞数据库比对。这套逻辑在 AI 场景下会遇到几个问题。第一AI 项目的依赖清单往往不完整。数据科学家的习惯是pip install直接装不更新requirements.txtNotebook 里的!pip install命令不会出现在任何清单文件里。第二AI 组件的版本管理很混乱。同一个模型文件可能有多个版本命名靠model_final_v2_真的最终版.pt这种玄学方式SCA 工具根本解析不了。第三漏洞数据库对 AI 组件的覆盖有限。CVE 里关于 PyTorch、TensorFlow 的漏洞不少但关于具体模型文件、Notebook 的漏洞信息几乎为零。我的建议是分层处理对 Python 包依赖继续用 SCA 工具但要确保扫描范围覆盖 Notebook 里的安装命令和虚拟环境对模型文件引入专门的 AI 安全扫描工具检查文件格式、序列化安全性、权重异常对数据管道配置做人工评审加自动化配置检查重点看数据流向和权限设置。Gartner 在报告中提到企业安全团队将越来越多地使用专门的 AI 安全厂商来扫描数据科学软件和 ML 管道中的漏洞。这个趋势背后的逻辑是通用工具做不到的事情需要专用工具来补位。选型时重点看三个能力能不能解析 AI 特有文件格式、能不能检测模型投毒和后门、能不能集成到 CI/CD 管道里做自动化扫描。3. AI 代理与自动化攻击凭证窃取和深度伪造的防御实操3.1 AI 代理如何把账户接管攻击提速 50%Gartner 预测到 2027 年AI 代理将进一步自动化凭证窃取和认证通信渠道的攻破把利用账户暴露的时间缩短 50%。这个预测的底层逻辑是账户接管ATO攻击链的每一步都在被 AI 代理加速。传统 ATO 攻击链大致是获取泄露凭证 → 用机器人尝试登录 → 如果失败尝试钓鱼获取更多信息 → 如果遇到 MFA尝试 OTP 拦截或推送轰炸。AI 代理的介入让每一步都更快、更自动化。比如AI 可以基于深度伪造语音做社会工程直接骗过帮助台重置密码AI 可以自动分析泄露数据筛选出高价值账户AI 可以自动生成钓鱼页面实时适配目标企业的登录界面。防御侧的关键动作Gartner 给了明确建议重新评估通信渠道和凭证安全特别是半自动化和即将到来的 AI 代理架构。具体落地时我一般会建议客户做这几件事第一全面盘点认证通信渠道。短信、邮件、语音电话、推送通知每一个渠道都要评估被拦截或伪造的风险。短信 OTP 的风险最高能换就换成 FIDO2 密钥或认证器应用。邮件 OTP 次之至少要确保邮件本身有 DMARC、SPF、DKIM 防护。语音电话如果用于密码重置必须加额外的验证步骤。第二对高权限账户强制硬件密钥。FIDO2 密钥是目前对抗钓鱼和凭证窃取最有效的手段。Gartner 也提到虽然 FIDO2 支持在增加但采用进度缓慢。我的经验是不要等全员推广先把管理员账户、财务系统账户、代码仓库账户这些高价值目标强制上硬件密钥效果立竿见影。第三监控异常认证行为。AI 代理自动化攻击的一个特征是“速度快、分布广”。同一个凭证在短时间内从多个 IP、多个设备尝试登录或者大量账户在短时间内触发密码重置这些都是信号。SIEM 规则要针对这些模式做调优不能只依赖传统的“多次失败锁定”策略。下面是一个简单的异常登录检测规则示例用 SQL 风格伪代码表示可以适配到大多数 SIEM 平台-- 检测同一账户在短时间内从多个地理位置登录 SELECT user_id, COUNT(DISTINCT geo_location) AS geo_count, COUNT(*) AS attempt_count, MIN(event_time) AS first_attempt, MAX(event_time) AS last_attempt FROM auth_events WHERE event_time NOW() - INTERVAL 10 minutes AND event_type IN (login_attempt, mfa_challenge) GROUP BY user_id HAVING COUNT(DISTINCT geo_location) 3 AND COUNT(*) 5 ORDER BY geo_count DESC; -- 检测推送轰炸同一用户在短时间内收到大量 MFA 推送 SELECT user_id, COUNT(*) AS push_count, MIN(event_time) AS first_push, MAX(event_time) AS last_push FROM mfa_events WHERE event_time NOW() - INTERVAL 5 minutes AND mfa_type push AND event_status sent GROUP BY user_id HAVING COUNT(*) 10 ORDER BY push_count DESC;第一条查询的逻辑是10 分钟内同一账户从超过 3 个不同地理位置尝试登录且尝试次数超过 5 次判定为可疑。参数可以根据你的业务特点调整——如果你的用户经常出差地理位置的阈值可以放宽如果你的业务集中在某个区域阈值可以收紧。第二条查询针对推送轰炸5 分钟内同一用户收到超过 10 次 MFA 推送这几乎可以确定是攻击者在尝试疲劳轰炸。发现这种情况后除了告警还应该自动触发临时锁定或要求额外的验证步骤。3.2 深度伪造攻击的检测与响应从语音到视频Gartner 预测到 2028 年40% 的社会工程攻击将不仅针对高管还会用深度伪造和其他伪造现实技术针对更广泛的员工群体。这个预测的潜台词是深度伪造攻击正在从“精准打击”变成“批量作业”。深度伪造的检测目前没有银弹。语音层面可以分析音频的频谱特征、呼吸模式、背景噪声一致性视频层面可以分析面部微表情、光影一致性、头部姿态与语音的同步性。但这些方法都有误报和漏报而且攻击技术在快速进化。我的实操建议是不要把深度伪造检测当成纯技术问题要结合流程控制。具体做法包括第一建立关键操作的“带外验证”流程。任何涉及资金转移、权限变更、敏感数据导出的操作不能仅凭一通电话或一个视频会议就执行。必须通过另一个独立渠道比如内部工单系统、面对面确认做二次验证。这个流程要写进 SOP并且定期演练。第二对高管和财务人员做深度伪造识别培训。培训内容不是让他们成为检测专家而是让他们知道“什么情况下可能遇到深度伪造攻击”以及“遇到时该怎么做”。比如接到要求紧急转账的语音电话时先挂断通过已知的可靠渠道回拨确认。第三部署 AI 威胁情报能力。Gartner 建议保持 AI 威胁情报功能并根据观察到的有害深度伪造攻击调整防御。这意味着你要持续关注深度伪造攻击的最新案例、工具和趋势而不是部署一次检测工具就完事。威胁情报的来源可以包括行业 ISAC、安全厂商报告、开源情报社区。注意深度伪造检测工具的误报率在真实环境中可能很高。如果用于自动化阻断务必设置人工复核环节否则可能影响正常业务沟通。4. 避坑与排查AI 安全落地中最容易翻车的五个地方4.1 坑一以为 SCA 工具能覆盖 AI 供应链现象安全团队用现有 SCA 工具扫描 AI 项目报告显示“无已知漏洞”但实际环境中发现了被投毒的开源模型。原因SCA 工具的扫描范围是依赖清单文件如requirements.txt、package.json而 AI 项目的模型文件、Notebook、管道配置不在扫描范围内。即使依赖清单里列了torch、tensorflowSCA 也只能检查这些包本身的已知 CVE无法检测模型权重是否被植入后门。解决明确 SCA 工具的覆盖边界对 AI 特有组件引入专门的扫描工具。在 CI/CD 管道里增加模型文件哈希校验和 Notebook 静态分析步骤。如果预算有限至少要对从外部来源引入的模型和 Notebook 做人工评审。4.2 坑二AI 资产盘点只做一次现象季度初完成了 AI 资产盘点季度末发现业务部门又上线了三个新的 AI 项目安全团队完全不知情。原因AI 项目的上线速度远快于传统应用业务部门用低代码平台或云服务可以快速搭建原型并投入生产。安全团队如果只做定期盘点永远追不上业务的速度。解决把 AI 资产发现嵌入到现有流程里。比如在云资源审批流程里增加“是否涉及 AI 组件”的必填项在代码仓库的 CI 管道里增加 AI 组件扫描步骤定期与业务侧开同步会了解即将上线的 AI 项目。工具方面可以考虑部署持续发现的 AI 资产管理平台自动扫描云环境和代码仓库。4.3 坑三把 AI 代理当普通自动化工具来管现象安全团队对 AI 代理的权限管理沿用传统服务账户的策略结果代理被攻击后攻击者利用代理的权限横向移动造成大面积影响。原因AI 代理的行为模式与传统自动化脚本不同。代理可能会动态调用外部 API、访问非结构化数据、与其他代理协作。传统的静态权限模型无法适应这种动态性。解决对 AI 代理实施最小权限原则但权限要动态调整。代理的每次操作都要有日志记录和审计追踪。对代理的通信渠道做加密和认证防止中间人攻击。定期对代理的行为做基线分析发现异常行为及时告警。4.4 坑四深度伪造检测工具直接上生产现象部署了深度伪造检测工具后正常的高管视频会议被频繁误报为“疑似深度伪造”导致业务部门对安全团队产生抵触。原因深度伪造检测的准确率在真实场景下受多种因素影响网络带宽导致的视频压缩、光线条件、摄像头质量、说话人的口音和语速。实验室环境的高准确率不等于生产环境的可用性。解决先在旁路模式运行检测工具收集误报和漏报数据调优阈值。在生产环境使用时检测结果只作为辅助信号不直接阻断。对高误报场景结合其他信号如登录地点、设备指纹、行为基线做综合判断。4.5 坑五忽略数据管道的配置安全现象攻击者通过篡改数据管道的配置把敏感训练数据重定向到外部服务器数据泄露持续了数周才被发现。原因数据管道的配置文件通常由数据工程师管理安全团队很少审查。配置错误如 S3 存储桶权限过宽、数据库连接字符串硬编码、外部 API 端点未做校验为攻击者提供了便捷的窃取通道。解决把数据管道配置纳入安全评审范围。对配置文件的变更做版本控制和审计。使用基础设施即代码IaC工具管理管道配置并在 CI 管道里做安全扫描如检查存储桶权限、检查外部端点白名单。对数据流向做监控发现异常外传及时阻断。5. 从战术到习惯把 AI 安全验证嵌入日常流程Gartner 在报告中有一个判断值得反复咀嚼到 2027 年90% 的成功 AI 安全实施将是战术性的——任务自动化和流程增强而不是角色替代。这个判断的实操含义是不要追求一步到位的“AI 安全大平台”而是从一个个具体的小任务开始把 AI 安全验证变成日常习惯。我自己的习惯是每引入一个新的 AI 组件——不管是开源模型、Notebook 还是 Python 包——都强制走一遍“三查一问”流程。一查来源这个组件从哪来的官方仓库、社区分享还是第三方市场来源的可信度直接决定后续审查的严格程度。二查哈希下载后立即计算哈希与官方提供的哈希比对如果有的话并记录到资产库。三查依赖这个组件引入了哪些间接依赖有没有已知漏洞一问用途这个组件要解决什么问题是否真的需要引入有没有更安全的替代方案这个流程听起来简单但坚持下来能挡住大部分供应链投毒的初级攻击。对于高级攻击——比如精心构造的模型后门——还需要专门的检测工具和人工审查。但至少你不会因为下载了一个被感染的 Notebook 而把整个训练环境暴露出去。验证方法方面我建议定期做“红队演练”模拟攻击者从供应链入手尝试投毒一个内部使用的开源模型或 Notebook看安全团队能否发现。这种演练的价值在于暴露流程中的盲区——比如你可能发现模型文件的哈希校验没有自动化或者 Notebook 的静态分析规则覆盖不全。每次演练后更新检查清单和自动化规则逐步把防御能力沉淀下来。从那以后我每次做 AI 项目安全评审都强制走一遍资产盘点、供应链扫描、配置审查和异常检测规则调优。这套流程不复杂但能让你在 AI 动荡期里少踩很多坑。希望帮到你。本文还有配套的精品资源点击获取