简介《Gartner预测2025应对AI驱动的网络安全新挑战与70%恶意攻击来自供应链和技术栈中毒》是一份AI安全趋势解读资料面向网络安全决策者、AI治理与供应链安全从业者。资料为单个PDF文件压缩包约215KB内容精炼便于通读。报告围绕AI动荡期展开指出早期GenAI部署效果不及预期、AI代理漂洗agent washing现象升温以及深度伪造、伪造语音等AI增强攻击规模化并预测到2025年针对企业AI的恶意攻击中超过70%将来自软件供应链和技术栈中毒。同时提出审查应用安全实践、优先成果驱动型AI项目、应对账号接管新浪潮、部署AI威胁情报等具体建议。适合需要制定2025年AI安全路线图或追踪Gartner战略规划假设的中高级安全专业人员可作为前沿参考。目前已有88人学习下载。1. 2025 年 AI 安全进入动荡期真正的风险不在模型本身而在供应链过去两年企业对生成式 AI 的认知经历了从狂热到落地的完整周期而 Gartner 这份 2025 年 2 月发布的研究报告《Predicts 2025: Navigating Imminent AI Turbulence for Cybersecurity》给出了一个容易让安全团队误判的结论未来一年对 AI 安全威胁最大的不是模型对抗、提示词注入这类听起来很新的攻击而是软件供应链投毒和基础设施技术栈中毒。报告预测到 2025 年超过 70% 针对企业中 AI 的恶意攻击来自供应链和技术栈层面而不是模型运行时本身。这意味着安全团队如果还把大部分精力放在跟风研究大模型提示词攻击而忽视了对 AI 软件组件库存的梳理接下来的攻击面会比你预想的宽得多。这篇文章的目标是把这份报告里可执行的部分拆开讲清楚供应链攻击的路径、AI 治理框架怎么落地、AI 代理带来的账号接管风险以及安全团队最容易踩的坑。适合正在做 AI 安全规划、需要向管理层解释预算优先级的安全负责人也适合正在给自己团队搭 AI 安全评估流程的一线工程师。2. 软件供应链投毒为什么 70% 的攻击落在 AI 的技术栈上2.1 攻击者的投入产出比决定了攻击路径报告里有一个值得反复读的关键判断黑客传统上倾向于在基础设施和供应链层面发起攻击除非目标是高度特定的组织。这个逻辑在 AI 场景下完全成立。对于一个攻击者来说直接攻击一个训练好的大模型运行时需要对抗 GPU 集群、模型防火墙、推理网关等层层防护成本高且单次收益有限。而攻击一个开源模型、一个 Jupyter Notebook、一个 Python 库或者一条数据管道一次投毒成功就能影响大量下游企业和应用。报告的原始数据也很直接Gartner 客户反馈显示专业 AI 安全厂商在企业客户现场定期扫描开源模型时发现高达 1% 的开源模型感染了恶意软件另外还发现了数千个被感染的数据科学笔记本。这不是理论推演是已经发生的现实。从攻击者的视角看AI 应用的技术栈比传统 Web 应用要长得多。一个典型的 AI 应用至少包含开源基础模型、微调训练脚本、数据预处理管道、推理服务、向量数据库、Prompt 模板、模型仓库、依赖的 Python 库。每一层都是投毒入口。更麻烦的是大多数企业连自己的 AI 资产清单都不完整报告里明确提到“AI 管道软件组件的不良库存”是当前应用安全程序最明显的弱点之一。很多传统应用安全工具还没进化到能扫描 AI 实体的漏洞这导致安全团队手里缺少可用工具来保护 AI 应用。我见过太多团队把 A 100 服务器当宝贝盯着却没人管训练数据是从哪个渠道拉来的、Notebook 里装了什么依赖、微调用的基础模型是不是官方渠道下载的。2.2 建立 AI 资产盘点第一步不是上工具是搞清楚家里有什么报告给的第一条建议是“建立 AI 应用的发现和库存流程”。这一步听起来朴素但做过的团队都知道工作量不小。资产盘点要覆盖的不只是模型本身而是整个 AI 技术栈。我一般会建议团队做一个分层清单模型层基础模型、微调模型、模型仓库、数据层训练集、测试集、数据管道、代码层训练脚本、推理服务、Notebook、基础设施层向量库、推理网关、模型服务。每一层都由对应的负责人确认资产来源和更新频率。一个实际可用的盘点脚本思路是这样的扫描项目目录识别所有模型文件、Python 依赖和 Notebook 文件输出一份基础清单。import os import json import hashlib # 需要盘点的目录按实际项目路径修改 base_dir /data/ai_projects # 关注的 AI 资产文件后缀 model_suffixes {.pt, .pth, .onnx, .gguf, .bin, .safetensors} notebook_suffixes {.ipynb} # 依赖清单文件名 requirement_files {requirements.txt, pyproject.toml, environment.yml} scan_result {models: [], notebooks: [], dependencies: []} for root, dirs, files in os.walk(base_dir): # 跳过虚拟环境和缓存目录避免噪音 dirs[:] [d for d in dirs if d not in {.git, __pycache__, venv, node_modules}] for file in files: file_path os.path.join(root, file) if any(file.endswith(suf) for suf in model_suffixes): # 计算 SHA256便于后续和官方发布值比对 sha256 hashlib.sha256(open(file_path, rb).read()).hexdigest() scan_result[models].append({ path: file_path, size_mb: round(os.path.getsize(file_path) / 1024 / 1024, 2), sha256: sha256 }) elif any(file.endswith(suf) for suf in notebook_suffixes): scan_result[notebooks].append({path: file_path}) elif file in requirement_files: scan_result[dependencies].append({path: file_path}) # 输出 JSON 格式的资产清单方便导入 CMDB 或资产管理系统 print(json.dumps(scan_result, indent2, ensure_asciiFalse))这段脚本做了几件事遍历指定目录识别模型文件、Notebook 和依赖清单对模型文件计算 SHA256 哈希值。哈希值的意义在于你可以把它和模型发布方的官方哈希值比对校验文件完整性。很多开源模型发布时会同时公布 SHA256下载后不校验直接用的团队不在少数这是个非常典型的安全盲区。脚本输出的是 JSON 格式方便后续导入资产管理系统或者作为 SCA 扫描的输入。参数层面的调整一般是base_dir 换成实际模型目录model_suffixes 按团队实际使用的框架增删比如 TensorFlow 的 .pb、.h5 也需要列入。盘点的结果应该形成一份 AI 资产清单而不是一份 Excel 表扔在那吃灰。报告里强调的“不要假设现有基础设施安全和漏洞扫描工具能正确处理 AI 组件”意思很明确传统 SCA 工具扫的是 Web 依赖AI 场景下的模型文件、Notebook、数据管道需要专门的扫描手段。现在不少厂商已经在做开源模型的恶意内容扫描也有专门的 AI 安全厂商提供 Jupyter Notebook 和 ML 管线的漏洞扫描服务。这些工具应该作为盘点流程的下一环接入而不是替代盘点。2.3 数据管线的隐蔽攻击面容易被大多数团队忽略的是数据管线本身。报告里专门提到攻击者可以利用用户对数据管线的错误配置把敏感数据偷偷传输到攻击者的服务器。攻击者认为攻击数据管线比逐个攻击运行时事务更有价值。这句话翻译一下就是你的数据管道只要配置稍有疏漏中间某一环被插入了一个恶意的数据读取组件敏感数据就会持续外流而且不一定能被及时发现因为管道本来就在持续搬运数据。针对数据管线的防护报告给出的建议是部署深度数据管道检查和机密计算等技术来保护工作负载防止恶意渗透或数据外泄。机密计算Confidential Computing在 AI 场景下的价值在于即使宿主机被攻破运行在可信执行环境TEE中的模型和数据的明文也不会暴露。这类基础设施级的方案部署成本不低我建议团队按数据敏感度分级决定是否启用。而对于数据管线的深度检查更现实的落地方式是对管道中的每一步做数据流审计标记所有外发流量并对异常的目标地址做告警。管道脚本里如果出现指向非预期外部域名的 HTTP 请求应该触发审查流程。3. AI 治理框架 TRiSM五层防护怎么落到日常安全工作里3.1 为什么是 TRiSM 而不是单点工具报告提到一个概念AI Trust、Risk and Security ManagementTRiSM以及对应的治理工具和框架。TRiSM 的核心思想是AI 安全不能靠单一工具解决而是要在信任、风险、安全三个维度上分层建设。在具体落地层面报告建议使用一个由 TRiSM 技术栈所有层组成的分层方法把防护重点从运行时向量扩展到软件供应链和基础设施技术栈。结合实际操作经验TRiSM 的五层我一般拆成模型风险管理模型本身的能力边界和弱点、数据防护训练数据、提示词数据、用户数据的隔离与保护、供应链安全模型来源、依赖扫描、版本校验、治理合规AI 使用政策、权限控制、审计日志、可观测性模型行为监控、异常输出检测、告警。每一层都有对应的工具和流程但大多数团队不需要一次性全部搭建而是应该按风险优先级渐进式建设。报告里有一个值得注意的观点安全和风险管理领导者对 GenAI 持谨慎乐观态度只有 12% 的人已经获得了可衡量的成果。这意味着大多数团队还处在探索期不必追求一步到位。3.2 模型选型与来源校验的实操清单供应链安全在 TRiSM 中对应的是最落地的一层。模型从哪里下载、如何校验、谁有权限加载新模型这些应该形成明确的流程。报告里给出的建议是启动对 AI 应用的软件组成分析SCA和漏洞评估项目不要假设现有的基础设施安全和漏洞扫描工具能正确处理 AI 组件。模型选型和来源校验的实操清单可以落到几个步骤。第一步是建立模型来源白名单Hugging Face 官方组织账号、模型官方发布渠道、企业私有仓库是首选个人账号和不明镜像源一律不进生产环境。第二步是校验哈希每个下载的模型文件都要和官方发布的 SHA256 比对不匹配的直接隔离。第三步是定期复扫已经部署的模型也要定期扫描新披露的 CVE 可能影响模型依赖的组件。第四步是依赖固定训练和推理环境的 Python 依赖要用完整性锁定不要用宽松的版本范围。以下是依赖锁定的一个常见做法在 requirements.txt 中固定精确版本并校验哈希# requirements.txt —— 生产环境依赖锁定示例 transformers4.44.0 --hashsha256:1a1e8f2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f torch2.3.1 --hashsha256:9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6依赖锁定的价值在于即使上游库被投毒或发布恶意新版本你的环境也不会因为一次 pip install 就拉到被污染的版本。这种做法在传统 Web 开发里已经普及但 AI 项目里大量团队还在直接用pip install transformers拉最新版这是 AI 技术栈供应链投毒的典型入口。报告里提到“传统应用安全工具还没进化到能集成 AI 实体的漏洞扫描”所以这部分现阶段更多要靠流程约束而不是指望工具自动挡。3.3 AI 治理工具与持续评估报告建议部署 AI 治理工具持续评估和确保所有 AI 资产的安全态势尤其是来自软件供应链的资产。治理工具的核心功能一般包括模型目录管理谁在用哪个模型、模型版本追踪、安全策略的自动化检查例如模型是否通过了安全扫描才能上线、以及定期安全态势报告。在工具选型之前我建议团队先回答三个问题一是你能否在五分钟内说清楚当前生产和测试环境里总共有多少个模型在运行二是每个模型的数据来源是否都有明确责任人三是新模型上线是否有固定的安全审批流程。三个问题如果答案是否定的直接上再贵的治理工具也只是在给混乱的流程做包装。工具解决的是执行效率问题前提是流程本身清晰。报告里提到 AI 治理要覆盖“所有 AI 资产”这个“所有”恰恰是很多团队做不到的——生产环境的模型管得严但数据科学家的 Notebook 里跑的实验模型、临时下载的开源模型常常完全在安全视野之外。治理的边界要从 Notebook 到生产环境全程拉通而不是只管正式发布的部分。4. AI 代理与账号接管身份攻击正在进入自动化时代4.1 ATO kill chain 的 AI 化改造报告里第三个核心预测是到 2027 年AI 代理将进一步提升凭证窃取和认证通信通道攻击的自动化程度最终把账号暴露的利用时间缩短 50%。这不是危言耸听而是顺着现有攻击链路的自然推演。传统账号接管ATO的链路是通过数据泄露、钓鱼、社交工程、恶意软件拿到弱密码然后用机器人自动在多个平台尝试撞库登录。整个过程里密码收集环节高度依赖人工社工效率有限。AI 代理介入后这条链路发生了两个关键变化。变化一是社工环节的自动化基于深度伪造语音的社交工程让攻击者可以用合成的声音冒充高管打电话给 IT 支持人员重置密码整个过程可以批量执行。变化二是凭证滥用环节的端到端自动化AI 代理可以自动完成从获取凭证、尝试登录、绕过 MFA、到在系统内横向移动的完整链条。报告里有一个更具体的预测到 2028 年40% 的社会工程攻击将不再只针对高管而是利用深度伪造和其他伪造现实技术攻击更广泛的员工群体。4.2 MFA 的盲区OTP 捕获与推送轰炸报告明确指出使用带外通信渠道的 MFA 方法本身就存在脆弱性通过短信或电子邮件发送的 OTP 可被拦截推送轰炸Push Bombing则通过不断向用户手机发送移动推送提示直到用户在烦躁中误点允许。这两种攻击方式对 AI 代理来说都是可以自动化的环节。所以在身份安全层面报告给出的方向很明确重新评估通信渠道和凭证安全尤其是在半自动化和即将到来的 AI 代理架构中。FIDO2 Passkey 是目前对抗这类攻击最有效的方案因为它是基于公钥密码学的不存在可被拦截的共享密钥也不存在可被轰炸的推送按钮。但 Gartner 在报告中也承认虽然大多数访问管理工具和一些大型消费者服务提供商现在支持 FIDO2 Passkey但企业和终端用户的采用进展缓慢密码这种传统凭证在可预见的未来还会持续存在。对安全团队来说现实的策略不是幻想短期内消灭密码而是分层缓解。我一般建议的做法是对高权限账户管理员、财务、IT 运维强制推行 Passkey 或硬件安全密钥对普通员工至少做到 MFA 全覆盖并且关闭短信 OTP 作为唯一因素对异常登录行为新设备、新地理位置、异常时间启用基于风险的自适应认证。报告里的核心预测提到“AI 代理将进一步自动化凭证窃取”这意味着撞库攻击的规模和速度都会显著提升单纯依赖密码复杂度已经不够必须把重心放到检测层面。4.3 员工培训与深度伪造防御报告建议“保持一个 AI 威胁情报功能并针对观察到的和有害的深度伪造攻击调整防御”同时“不要因为恐慌而放弃对新威胁的防备”。深度伪造攻击已经开始出现在真实案例里CEO 语音钓鱼、视频会议中伪造高管的形象这些不再是电影情节。防御这类攻击光靠技术手段不够必须在流程上建立验证机制。具体措施我可以给几个方向。一是高价值操作的双通道验证涉及资金转账、密码重置、敏感信息导出等操作除了常规审批外增加一个独立的验证通道例如当面确认或通过已验证的内部即时通讯工具二次确认。二是对语音和视频会议中的敏感指令建立话术验证码机制团队内部约定一个只有正式成员知道的随机验证码视频或电话中的关键指令必须能对上验证码才算有效。三是部署深度伪造检测工具对关键视频会议和语音留言做自动化检测但要把这些工具的输出当作提示信号而非最终结论。四是培训内容升级把“验证身份”从理念层面落到具体操作步骤让员工知道收到高管语音消息时应该做什么、不应该做什么。5. 避坑手册AI 安全项目里的典型翻车现场5.1 现象AI 安全助理部署后没人用安全团队丧失信心原因早期 GenAI 实验期望值过高部署的 AI 助理产出的告警误报率高或者跟现有工作流集成不顺畅导致安全分析师觉得用 AI 还不如手工作业慢慢就弃用了。报告里提到“早期 GenAI 实验的挫折侵蚀了安全团队对 GenAI 潜力的信心”这个现象的综合症是你花大价钱部署了 AI 工具结果团队反而更抗拒 AI。解决把期望从“AI 帮我搞定一切”调整为“AI 帮我处理最琐碎的那部分”。从投入产出比最高的单点任务开始比如告警去重、日志摘要、漏洞报告生成。每一项都设定明确的量化指标处理时间缩短多少、误报率降到多少用数据说话。报告里给的核心建议很简单成果驱动的 AI 计划而不是目标不清、范围模糊、难以衡量的转型项目。小规模实验 持续评估比一次性搞大平台靠谱得多。5.2 现象开源模型扫描发现感染但安全团队无从下手原因模型文件不像可执行文件那样有清晰的病毒特征恶意内容可能藏在模型的权重参数里也可能是模型的 tokenizer 或配置文件里被注入了恶意代码。另外模型文件动辄几 GB常规杀毒软件根本不扫这种文件。没有专门的扫描工具和响应流程即使扫出了问题也不知道该隔离还是该删除。解决先建立隔离流程扫描出问题的模型立即从模型仓库下线并移动到隔离区禁止任何推理服务继续加载。然后记录感染类型和文件路径判断影响范围这个模型被哪些服务引用过、输入数据是否可能已被影响。部署专门的模型扫描工具定期扫全量模型而不仅仅是新下载的。报告里提到专业 AI 安全厂商在企业现场扫描开源模型时约 1% 的感染率这个比例意味着如果你的模型仓库里有几百个模型中招几乎只是时间问题。5.3 现象数据管线配置错误导致敏感数据外泄几天后才发现原因数据管道的错误配置例如存储桶权限过于宽松、管道输出写入到公开位置、日志中包含敏感字段导致数据被窃取但管道本身运行正常没有触发任何告警。报告里很直接地指出攻击者发现攻击数据管道比攻击运行时事务带来的收益高得多。数据管道持续搬运数据数据被多复制一份到攻击者服务器短时间内在数据量和传输模式上不会出现明显异常。解决对数据管道做全面的配置审计重点检查外部存储的权限设置、日志是否包含敏感信息、管道代码中是否引用了非预期外部域名。建立数据外流检测对所有管道的外发流量做白名单控制非白名单目标地址直接阻断并告警。配备深度数据检查能力对管道传输内容的敏感字段做识别和标记。5.4 现象AI 代理权限过大一个代理被攻破等于整个系统失守原因很多团队部署 AI 代理时给代理的 API 权限和账号权限是“能用就行”的思路没有做最小权限设计。AI 代理在执行自动化任务时如果被提示词注入攻击利用攻击者就能通过代理拿到系统访问权限。报告里提醒 AI 代理会进一步自动化凭证窃取并危及认证通信渠道代理本身如果安全防护不到位就会成为攻击者的最佳跳板。解决AI 代理的权限设计遵循最小权限原则每个代理只能调用完成其任务所必需的 API 和数据源代理之间的权限相互隔离避免一次攻破就横向扩散。对代理的输入输出做持续监控代理执行的关键操作发邮件、改权限、调用管理接口需要额外审批。定期用对抗性提示词测试代理的行为验证代理在恶意输入下的表现是否可控。5.5 现象AI 安全项目做了半年管理层问“成果是什么”时拿不出数据原因项目启动时没有定义量化的成功指标做了一堆安全加固动作但没有建立“加固前后对比”的度量体系。报告里给了一个很有力的背景数据只有 12% 的安全领导者从 GenAI 中获得了可衡量的结果。这个数字说明大多数团队在 AI 安全项目上的投入产出比是模糊的这会在后续预算争取时非常被动。解决每个 AI 安全项目启动时先定义 2 到 3 个核心指标例如“AI 资产盘点覆盖率从 X% 提升到 Y%”“模型上线前的平均安全审查时间从 X 天缩短到 Y 天”“供应链扫描频率从每月一次提升到每周一次”。按月输出指标趋势用数据向管理层展示项目进展。报告里提到的战术型实施任务自动化和流程增强比角色替代型实施更容易量化成果所以指标尽量落在具体任务的效率提升上而不是宏大的“安全能力建设”这类无法量化的话。6. 落地技巧用战术型 AI 试点验证价值别信“全自动替换”的承诺进入 2025 年安全市场里关于 AI 代理的宣传会越来越猛报告对此的定性很准确AI 代理正接近炒作顶峰需要 5 到 10 年才能进入生产成熟期。安全团队要做好两件事一是扛住“全自动安全运营”这类宣传的压力二是用可度量的实验验证哪些场景真的适合 AI 介入。我现在的做法是强制自己用“战术试点 人工抽验”的方式来评估每一个 AI 安全项目。具体操作是选一个明确的、边界清晰的单点任务比如漏洞优先级排序或者告警分类部署一个 AI 助理设置前两周为评估期。评估期内要求分析师对 AI 的输出做抽验抽验比例不低干 20%每次抽验都记录 AI 判断是否正确、不正确的原因是什么。两周后统计准确率和人工修正成本再决定是扩大范围、调整模型还是终止项目。报告里专门建议“保持定期人工验证作为半自动化工作流的一部分”并且要在测试期和生产期都持续执行这个建议我深有体会——很多团队在测试期认真做人工抽验一上生产就把抽验停了等于把 AI 的输出当成了事实这是后续翻车的隐患。评估指标方面我习惯用一张简单的表来对比试点前后的数据任务平均处理时间分钟、人工介入率%、错误率%、单次任务成本折算人力。表格格式如下指标试点前人工试点后AI 辅助变化告警分类平均耗时45 分钟/天15 分钟/天缩短 67%人工介入率100%35%降低 65%分类错误率8%5%降低 3%单日投入人力2 人小时0.7 人小时节省 65%在模型部署方式上报告里也给出了一个值得参考的方向战术型实施可以让团队把商业工具和私有化部署的模型混用打开新的使用场景。我实践下来的感受是对于安全分析这类数据敏感度高的任务至少要把日志摘要、告警解释这类场景的模型私有化部署数据不出内网而对于威胁情报摘要这类依赖外部数据的任务可以用商业 API 服务。这种混合模式既控制数据风险又保持灵活性。最后说一个我个人的习惯从那以后我每次评估一个新的 AI 安全工具都会强制走一遍“定义指标 → 小规模试点 → 定期人工抽验 → 用数据决定去留”这个流程不管厂商的宣传多诱人、销售的话术多紧迫都让数据说话。希望帮到你。本文还有配套的精品资源点击获取 2025 AI安全供应链风险与TRiSM治理落地指南
简介《Gartner预测2025应对AI驱动的网络安全新挑战与70%恶意攻击来自供应链和技术栈中毒》是一份AI安全趋势解读资料面向网络安全决策者、AI治理与供应链安全从业者。资料为单个PDF文件压缩包约215KB内容精炼便于通读。报告围绕AI动荡期展开指出早期GenAI部署效果不及预期、AI代理漂洗agent washing现象升温以及深度伪造、伪造语音等AI增强攻击规模化并预测到2025年针对企业AI的恶意攻击中超过70%将来自软件供应链和技术栈中毒。同时提出审查应用安全实践、优先成果驱动型AI项目、应对账号接管新浪潮、部署AI威胁情报等具体建议。适合需要制定2025年AI安全路线图或追踪Gartner战略规划假设的中高级安全专业人员可作为前沿参考。目前已有88人学习下载。1. 2025 年 AI 安全进入动荡期真正的风险不在模型本身而在供应链过去两年企业对生成式 AI 的认知经历了从狂热到落地的完整周期而 Gartner 这份 2025 年 2 月发布的研究报告《Predicts 2025: Navigating Imminent AI Turbulence for Cybersecurity》给出了一个容易让安全团队误判的结论未来一年对 AI 安全威胁最大的不是模型对抗、提示词注入这类听起来很新的攻击而是软件供应链投毒和基础设施技术栈中毒。报告预测到 2025 年超过 70% 针对企业中 AI 的恶意攻击来自供应链和技术栈层面而不是模型运行时本身。这意味着安全团队如果还把大部分精力放在跟风研究大模型提示词攻击而忽视了对 AI 软件组件库存的梳理接下来的攻击面会比你预想的宽得多。这篇文章的目标是把这份报告里可执行的部分拆开讲清楚供应链攻击的路径、AI 治理框架怎么落地、AI 代理带来的账号接管风险以及安全团队最容易踩的坑。适合正在做 AI 安全规划、需要向管理层解释预算优先级的安全负责人也适合正在给自己团队搭 AI 安全评估流程的一线工程师。2. 软件供应链投毒为什么 70% 的攻击落在 AI 的技术栈上2.1 攻击者的投入产出比决定了攻击路径报告里有一个值得反复读的关键判断黑客传统上倾向于在基础设施和供应链层面发起攻击除非目标是高度特定的组织。这个逻辑在 AI 场景下完全成立。对于一个攻击者来说直接攻击一个训练好的大模型运行时需要对抗 GPU 集群、模型防火墙、推理网关等层层防护成本高且单次收益有限。而攻击一个开源模型、一个 Jupyter Notebook、一个 Python 库或者一条数据管道一次投毒成功就能影响大量下游企业和应用。报告的原始数据也很直接Gartner 客户反馈显示专业 AI 安全厂商在企业客户现场定期扫描开源模型时发现高达 1% 的开源模型感染了恶意软件另外还发现了数千个被感染的数据科学笔记本。这不是理论推演是已经发生的现实。从攻击者的视角看AI 应用的技术栈比传统 Web 应用要长得多。一个典型的 AI 应用至少包含开源基础模型、微调训练脚本、数据预处理管道、推理服务、向量数据库、Prompt 模板、模型仓库、依赖的 Python 库。每一层都是投毒入口。更麻烦的是大多数企业连自己的 AI 资产清单都不完整报告里明确提到“AI 管道软件组件的不良库存”是当前应用安全程序最明显的弱点之一。很多传统应用安全工具还没进化到能扫描 AI 实体的漏洞这导致安全团队手里缺少可用工具来保护 AI 应用。我见过太多团队把 A 100 服务器当宝贝盯着却没人管训练数据是从哪个渠道拉来的、Notebook 里装了什么依赖、微调用的基础模型是不是官方渠道下载的。2.2 建立 AI 资产盘点第一步不是上工具是搞清楚家里有什么报告给的第一条建议是“建立 AI 应用的发现和库存流程”。这一步听起来朴素但做过的团队都知道工作量不小。资产盘点要覆盖的不只是模型本身而是整个 AI 技术栈。我一般会建议团队做一个分层清单模型层基础模型、微调模型、模型仓库、数据层训练集、测试集、数据管道、代码层训练脚本、推理服务、Notebook、基础设施层向量库、推理网关、模型服务。每一层都由对应的负责人确认资产来源和更新频率。一个实际可用的盘点脚本思路是这样的扫描项目目录识别所有模型文件、Python 依赖和 Notebook 文件输出一份基础清单。import os import json import hashlib # 需要盘点的目录按实际项目路径修改 base_dir /data/ai_projects # 关注的 AI 资产文件后缀 model_suffixes {.pt, .pth, .onnx, .gguf, .bin, .safetensors} notebook_suffixes {.ipynb} # 依赖清单文件名 requirement_files {requirements.txt, pyproject.toml, environment.yml} scan_result {models: [], notebooks: [], dependencies: []} for root, dirs, files in os.walk(base_dir): # 跳过虚拟环境和缓存目录避免噪音 dirs[:] [d for d in dirs if d not in {.git, __pycache__, venv, node_modules}] for file in files: file_path os.path.join(root, file) if any(file.endswith(suf) for suf in model_suffixes): # 计算 SHA256便于后续和官方发布值比对 sha256 hashlib.sha256(open(file_path, rb).read()).hexdigest() scan_result[models].append({ path: file_path, size_mb: round(os.path.getsize(file_path) / 1024 / 1024, 2), sha256: sha256 }) elif any(file.endswith(suf) for suf in notebook_suffixes): scan_result[notebooks].append({path: file_path}) elif file in requirement_files: scan_result[dependencies].append({path: file_path}) # 输出 JSON 格式的资产清单方便导入 CMDB 或资产管理系统 print(json.dumps(scan_result, indent2, ensure_asciiFalse))这段脚本做了几件事遍历指定目录识别模型文件、Notebook 和依赖清单对模型文件计算 SHA256 哈希值。哈希值的意义在于你可以把它和模型发布方的官方哈希值比对校验文件完整性。很多开源模型发布时会同时公布 SHA256下载后不校验直接用的团队不在少数这是个非常典型的安全盲区。脚本输出的是 JSON 格式方便后续导入资产管理系统或者作为 SCA 扫描的输入。参数层面的调整一般是base_dir 换成实际模型目录model_suffixes 按团队实际使用的框架增删比如 TensorFlow 的 .pb、.h5 也需要列入。盘点的结果应该形成一份 AI 资产清单而不是一份 Excel 表扔在那吃灰。报告里强调的“不要假设现有基础设施安全和漏洞扫描工具能正确处理 AI 组件”意思很明确传统 SCA 工具扫的是 Web 依赖AI 场景下的模型文件、Notebook、数据管道需要专门的扫描手段。现在不少厂商已经在做开源模型的恶意内容扫描也有专门的 AI 安全厂商提供 Jupyter Notebook 和 ML 管线的漏洞扫描服务。这些工具应该作为盘点流程的下一环接入而不是替代盘点。2.3 数据管线的隐蔽攻击面容易被大多数团队忽略的是数据管线本身。报告里专门提到攻击者可以利用用户对数据管线的错误配置把敏感数据偷偷传输到攻击者的服务器。攻击者认为攻击数据管线比逐个攻击运行时事务更有价值。这句话翻译一下就是你的数据管道只要配置稍有疏漏中间某一环被插入了一个恶意的数据读取组件敏感数据就会持续外流而且不一定能被及时发现因为管道本来就在持续搬运数据。针对数据管线的防护报告给出的建议是部署深度数据管道检查和机密计算等技术来保护工作负载防止恶意渗透或数据外泄。机密计算Confidential Computing在 AI 场景下的价值在于即使宿主机被攻破运行在可信执行环境TEE中的模型和数据的明文也不会暴露。这类基础设施级的方案部署成本不低我建议团队按数据敏感度分级决定是否启用。而对于数据管线的深度检查更现实的落地方式是对管道中的每一步做数据流审计标记所有外发流量并对异常的目标地址做告警。管道脚本里如果出现指向非预期外部域名的 HTTP 请求应该触发审查流程。3. AI 治理框架 TRiSM五层防护怎么落到日常安全工作里3.1 为什么是 TRiSM 而不是单点工具报告提到一个概念AI Trust、Risk and Security ManagementTRiSM以及对应的治理工具和框架。TRiSM 的核心思想是AI 安全不能靠单一工具解决而是要在信任、风险、安全三个维度上分层建设。在具体落地层面报告建议使用一个由 TRiSM 技术栈所有层组成的分层方法把防护重点从运行时向量扩展到软件供应链和基础设施技术栈。结合实际操作经验TRiSM 的五层我一般拆成模型风险管理模型本身的能力边界和弱点、数据防护训练数据、提示词数据、用户数据的隔离与保护、供应链安全模型来源、依赖扫描、版本校验、治理合规AI 使用政策、权限控制、审计日志、可观测性模型行为监控、异常输出检测、告警。每一层都有对应的工具和流程但大多数团队不需要一次性全部搭建而是应该按风险优先级渐进式建设。报告里有一个值得注意的观点安全和风险管理领导者对 GenAI 持谨慎乐观态度只有 12% 的人已经获得了可衡量的成果。这意味着大多数团队还处在探索期不必追求一步到位。3.2 模型选型与来源校验的实操清单供应链安全在 TRiSM 中对应的是最落地的一层。模型从哪里下载、如何校验、谁有权限加载新模型这些应该形成明确的流程。报告里给出的建议是启动对 AI 应用的软件组成分析SCA和漏洞评估项目不要假设现有的基础设施安全和漏洞扫描工具能正确处理 AI 组件。模型选型和来源校验的实操清单可以落到几个步骤。第一步是建立模型来源白名单Hugging Face 官方组织账号、模型官方发布渠道、企业私有仓库是首选个人账号和不明镜像源一律不进生产环境。第二步是校验哈希每个下载的模型文件都要和官方发布的 SHA256 比对不匹配的直接隔离。第三步是定期复扫已经部署的模型也要定期扫描新披露的 CVE 可能影响模型依赖的组件。第四步是依赖固定训练和推理环境的 Python 依赖要用完整性锁定不要用宽松的版本范围。以下是依赖锁定的一个常见做法在 requirements.txt 中固定精确版本并校验哈希# requirements.txt —— 生产环境依赖锁定示例 transformers4.44.0 --hashsha256:1a1e8f2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f torch2.3.1 --hashsha256:9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6依赖锁定的价值在于即使上游库被投毒或发布恶意新版本你的环境也不会因为一次 pip install 就拉到被污染的版本。这种做法在传统 Web 开发里已经普及但 AI 项目里大量团队还在直接用pip install transformers拉最新版这是 AI 技术栈供应链投毒的典型入口。报告里提到“传统应用安全工具还没进化到能集成 AI 实体的漏洞扫描”所以这部分现阶段更多要靠流程约束而不是指望工具自动挡。3.3 AI 治理工具与持续评估报告建议部署 AI 治理工具持续评估和确保所有 AI 资产的安全态势尤其是来自软件供应链的资产。治理工具的核心功能一般包括模型目录管理谁在用哪个模型、模型版本追踪、安全策略的自动化检查例如模型是否通过了安全扫描才能上线、以及定期安全态势报告。在工具选型之前我建议团队先回答三个问题一是你能否在五分钟内说清楚当前生产和测试环境里总共有多少个模型在运行二是每个模型的数据来源是否都有明确责任人三是新模型上线是否有固定的安全审批流程。三个问题如果答案是否定的直接上再贵的治理工具也只是在给混乱的流程做包装。工具解决的是执行效率问题前提是流程本身清晰。报告里提到 AI 治理要覆盖“所有 AI 资产”这个“所有”恰恰是很多团队做不到的——生产环境的模型管得严但数据科学家的 Notebook 里跑的实验模型、临时下载的开源模型常常完全在安全视野之外。治理的边界要从 Notebook 到生产环境全程拉通而不是只管正式发布的部分。4. AI 代理与账号接管身份攻击正在进入自动化时代4.1 ATO kill chain 的 AI 化改造报告里第三个核心预测是到 2027 年AI 代理将进一步提升凭证窃取和认证通信通道攻击的自动化程度最终把账号暴露的利用时间缩短 50%。这不是危言耸听而是顺着现有攻击链路的自然推演。传统账号接管ATO的链路是通过数据泄露、钓鱼、社交工程、恶意软件拿到弱密码然后用机器人自动在多个平台尝试撞库登录。整个过程里密码收集环节高度依赖人工社工效率有限。AI 代理介入后这条链路发生了两个关键变化。变化一是社工环节的自动化基于深度伪造语音的社交工程让攻击者可以用合成的声音冒充高管打电话给 IT 支持人员重置密码整个过程可以批量执行。变化二是凭证滥用环节的端到端自动化AI 代理可以自动完成从获取凭证、尝试登录、绕过 MFA、到在系统内横向移动的完整链条。报告里有一个更具体的预测到 2028 年40% 的社会工程攻击将不再只针对高管而是利用深度伪造和其他伪造现实技术攻击更广泛的员工群体。4.2 MFA 的盲区OTP 捕获与推送轰炸报告明确指出使用带外通信渠道的 MFA 方法本身就存在脆弱性通过短信或电子邮件发送的 OTP 可被拦截推送轰炸Push Bombing则通过不断向用户手机发送移动推送提示直到用户在烦躁中误点允许。这两种攻击方式对 AI 代理来说都是可以自动化的环节。所以在身份安全层面报告给出的方向很明确重新评估通信渠道和凭证安全尤其是在半自动化和即将到来的 AI 代理架构中。FIDO2 Passkey 是目前对抗这类攻击最有效的方案因为它是基于公钥密码学的不存在可被拦截的共享密钥也不存在可被轰炸的推送按钮。但 Gartner 在报告中也承认虽然大多数访问管理工具和一些大型消费者服务提供商现在支持 FIDO2 Passkey但企业和终端用户的采用进展缓慢密码这种传统凭证在可预见的未来还会持续存在。对安全团队来说现实的策略不是幻想短期内消灭密码而是分层缓解。我一般建议的做法是对高权限账户管理员、财务、IT 运维强制推行 Passkey 或硬件安全密钥对普通员工至少做到 MFA 全覆盖并且关闭短信 OTP 作为唯一因素对异常登录行为新设备、新地理位置、异常时间启用基于风险的自适应认证。报告里的核心预测提到“AI 代理将进一步自动化凭证窃取”这意味着撞库攻击的规模和速度都会显著提升单纯依赖密码复杂度已经不够必须把重心放到检测层面。4.3 员工培训与深度伪造防御报告建议“保持一个 AI 威胁情报功能并针对观察到的和有害的深度伪造攻击调整防御”同时“不要因为恐慌而放弃对新威胁的防备”。深度伪造攻击已经开始出现在真实案例里CEO 语音钓鱼、视频会议中伪造高管的形象这些不再是电影情节。防御这类攻击光靠技术手段不够必须在流程上建立验证机制。具体措施我可以给几个方向。一是高价值操作的双通道验证涉及资金转账、密码重置、敏感信息导出等操作除了常规审批外增加一个独立的验证通道例如当面确认或通过已验证的内部即时通讯工具二次确认。二是对语音和视频会议中的敏感指令建立话术验证码机制团队内部约定一个只有正式成员知道的随机验证码视频或电话中的关键指令必须能对上验证码才算有效。三是部署深度伪造检测工具对关键视频会议和语音留言做自动化检测但要把这些工具的输出当作提示信号而非最终结论。四是培训内容升级把“验证身份”从理念层面落到具体操作步骤让员工知道收到高管语音消息时应该做什么、不应该做什么。5. 避坑手册AI 安全项目里的典型翻车现场5.1 现象AI 安全助理部署后没人用安全团队丧失信心原因早期 GenAI 实验期望值过高部署的 AI 助理产出的告警误报率高或者跟现有工作流集成不顺畅导致安全分析师觉得用 AI 还不如手工作业慢慢就弃用了。报告里提到“早期 GenAI 实验的挫折侵蚀了安全团队对 GenAI 潜力的信心”这个现象的综合症是你花大价钱部署了 AI 工具结果团队反而更抗拒 AI。解决把期望从“AI 帮我搞定一切”调整为“AI 帮我处理最琐碎的那部分”。从投入产出比最高的单点任务开始比如告警去重、日志摘要、漏洞报告生成。每一项都设定明确的量化指标处理时间缩短多少、误报率降到多少用数据说话。报告里给的核心建议很简单成果驱动的 AI 计划而不是目标不清、范围模糊、难以衡量的转型项目。小规模实验 持续评估比一次性搞大平台靠谱得多。5.2 现象开源模型扫描发现感染但安全团队无从下手原因模型文件不像可执行文件那样有清晰的病毒特征恶意内容可能藏在模型的权重参数里也可能是模型的 tokenizer 或配置文件里被注入了恶意代码。另外模型文件动辄几 GB常规杀毒软件根本不扫这种文件。没有专门的扫描工具和响应流程即使扫出了问题也不知道该隔离还是该删除。解决先建立隔离流程扫描出问题的模型立即从模型仓库下线并移动到隔离区禁止任何推理服务继续加载。然后记录感染类型和文件路径判断影响范围这个模型被哪些服务引用过、输入数据是否可能已被影响。部署专门的模型扫描工具定期扫全量模型而不仅仅是新下载的。报告里提到专业 AI 安全厂商在企业现场扫描开源模型时约 1% 的感染率这个比例意味着如果你的模型仓库里有几百个模型中招几乎只是时间问题。5.3 现象数据管线配置错误导致敏感数据外泄几天后才发现原因数据管道的错误配置例如存储桶权限过于宽松、管道输出写入到公开位置、日志中包含敏感字段导致数据被窃取但管道本身运行正常没有触发任何告警。报告里很直接地指出攻击者发现攻击数据管道比攻击运行时事务带来的收益高得多。数据管道持续搬运数据数据被多复制一份到攻击者服务器短时间内在数据量和传输模式上不会出现明显异常。解决对数据管道做全面的配置审计重点检查外部存储的权限设置、日志是否包含敏感信息、管道代码中是否引用了非预期外部域名。建立数据外流检测对所有管道的外发流量做白名单控制非白名单目标地址直接阻断并告警。配备深度数据检查能力对管道传输内容的敏感字段做识别和标记。5.4 现象AI 代理权限过大一个代理被攻破等于整个系统失守原因很多团队部署 AI 代理时给代理的 API 权限和账号权限是“能用就行”的思路没有做最小权限设计。AI 代理在执行自动化任务时如果被提示词注入攻击利用攻击者就能通过代理拿到系统访问权限。报告里提醒 AI 代理会进一步自动化凭证窃取并危及认证通信渠道代理本身如果安全防护不到位就会成为攻击者的最佳跳板。解决AI 代理的权限设计遵循最小权限原则每个代理只能调用完成其任务所必需的 API 和数据源代理之间的权限相互隔离避免一次攻破就横向扩散。对代理的输入输出做持续监控代理执行的关键操作发邮件、改权限、调用管理接口需要额外审批。定期用对抗性提示词测试代理的行为验证代理在恶意输入下的表现是否可控。5.5 现象AI 安全项目做了半年管理层问“成果是什么”时拿不出数据原因项目启动时没有定义量化的成功指标做了一堆安全加固动作但没有建立“加固前后对比”的度量体系。报告里给了一个很有力的背景数据只有 12% 的安全领导者从 GenAI 中获得了可衡量的结果。这个数字说明大多数团队在 AI 安全项目上的投入产出比是模糊的这会在后续预算争取时非常被动。解决每个 AI 安全项目启动时先定义 2 到 3 个核心指标例如“AI 资产盘点覆盖率从 X% 提升到 Y%”“模型上线前的平均安全审查时间从 X 天缩短到 Y 天”“供应链扫描频率从每月一次提升到每周一次”。按月输出指标趋势用数据向管理层展示项目进展。报告里提到的战术型实施任务自动化和流程增强比角色替代型实施更容易量化成果所以指标尽量落在具体任务的效率提升上而不是宏大的“安全能力建设”这类无法量化的话。6. 落地技巧用战术型 AI 试点验证价值别信“全自动替换”的承诺进入 2025 年安全市场里关于 AI 代理的宣传会越来越猛报告对此的定性很准确AI 代理正接近炒作顶峰需要 5 到 10 年才能进入生产成熟期。安全团队要做好两件事一是扛住“全自动安全运营”这类宣传的压力二是用可度量的实验验证哪些场景真的适合 AI 介入。我现在的做法是强制自己用“战术试点 人工抽验”的方式来评估每一个 AI 安全项目。具体操作是选一个明确的、边界清晰的单点任务比如漏洞优先级排序或者告警分类部署一个 AI 助理设置前两周为评估期。评估期内要求分析师对 AI 的输出做抽验抽验比例不低干 20%每次抽验都记录 AI 判断是否正确、不正确的原因是什么。两周后统计准确率和人工修正成本再决定是扩大范围、调整模型还是终止项目。报告里专门建议“保持定期人工验证作为半自动化工作流的一部分”并且要在测试期和生产期都持续执行这个建议我深有体会——很多团队在测试期认真做人工抽验一上生产就把抽验停了等于把 AI 的输出当成了事实这是后续翻车的隐患。评估指标方面我习惯用一张简单的表来对比试点前后的数据任务平均处理时间分钟、人工介入率%、错误率%、单次任务成本折算人力。表格格式如下指标试点前人工试点后AI 辅助变化告警分类平均耗时45 分钟/天15 分钟/天缩短 67%人工介入率100%35%降低 65%分类错误率8%5%降低 3%单日投入人力2 人小时0.7 人小时节省 65%在模型部署方式上报告里也给出了一个值得参考的方向战术型实施可以让团队把商业工具和私有化部署的模型混用打开新的使用场景。我实践下来的感受是对于安全分析这类数据敏感度高的任务至少要把日志摘要、告警解释这类场景的模型私有化部署数据不出内网而对于威胁情报摘要这类依赖外部数据的任务可以用商业 API 服务。这种混合模式既控制数据风险又保持灵活性。最后说一个我个人的习惯从那以后我每次评估一个新的 AI 安全工具都会强制走一遍“定义指标 → 小规模试点 → 定期人工抽验 → 用数据决定去留”这个流程不管厂商的宣传多诱人、销售的话术多紧迫都让数据说话。希望帮到你。本文还有配套的精品资源点击获取