最近一次AI推理服务上线前的安全评审我上来就问了一句这个系统的漏洞清单什么时候能清零会议室一下子安静了。传统做法里漏洞管理无非是扫一扫、排个期、打补丁可到了AI系统里没人能答上来“边界”到底划在哪。从模型参数、训练数据到PyTorch、推理框架、异构计算依赖再到服务器固件、驱动、管理控制器攻击面早就从单一应用代码扩展到了整条算力链。那段时间我们正好请了一线算力厂商的工程师帮忙做架构评审其中就有海光的安全团队。聊了几轮之后我才真正意识到所谓“AI安全底座”不是靠在AI组件外面堆防护而是要把漏洞治理这件事前置到芯片和平台层。这篇文章就把我从这几轮交流里整理出来的思路以及一套可以落地的漏洞治理链路完整写出来。1. AI时代的攻击面早就不是“补丁游戏”那么简单了1.1 传统漏洞治理是“单点修补”AI时代的漏洞是“链路传导”过去我们做业务系统的漏洞治理基本逻辑是“边界防御补丁管理”防火墙封住端口WAF挡住Web攻击操作系统和中间件定时打补丁。每个漏洞相对独立修完一个就少一个安全团队按清单推进就行。AI系统完全不是这么回事。一次成功的攻击往往不直接发生在模型上而是先打穿某个依赖链节点再横向移动到数据或训练环境。举例来说训练数据投毒攻击者根本不需要攻破你的模型接口只要在训练数据集的来源处混入少量恶意样本模型行为就可能被悄悄带偏你从最终效果上几乎看不出异常。再比如提示注入对方不用碰服务器上的任何文件只要精心构造一段输入文本就能操纵模型输出甚至触发工具调用。这类漏洞的修复动作很难定位到某一个文件因为问题本质出在数据和指令这一层而已有的漏洞管理流程根本不管“数据”算不算漏洞。还有供应链风险。一个AI推理服务的基础依赖可能包含几十个开源组件每个组件都只承担整体的一小部分但任何一个组件的CVE都可能被放大成整套服务的沦陷。传统漏洞管理盯的是“已知漏洞列表”AI时代的漏洞治理更需要“链路影响分析”不仅要回答哪里有漏洞还要回答这个漏洞在整条调用链上能否被触达、能顺藤摸瓜波及哪些资产、横向移动的路径有几条。这些问题靠原来那张扫描报告是回答不了的。1.2 模型、框架、驱动、固件四个容易被忽略的隐蔽层我复盘过一些真实攻击案例有个很强烈的感受大家熟悉Web漏洞、熟悉容器漏洞但很少把“模型文件本身”和“算力硬件层”当作安全对象。先说模型层。模型文件不只是“一堆权重”现在很多模型格式支持自定义算子、自定义脚本在反序列化阶段就可能触发任意代码执行。你从第三方站点下载一个微调好的模型本质上和下载一个可执行文件的风险是类似的。但我们不少团队的资产管理里根本没有“模型资产”这一项更别说对模型文件做哈希校验或签名验证。再说框架层。深度学习框架版本迭代很快CVE也几乎每个月都有新增。问题在于框架升级往往不是改一行版本号就能完事它会牵动驱动、编译依赖、算子库兼容跳一个大版本可能带来明显的推理性能回退。所以很多团队明知道旧版本有洞也不敢升宁可捂着。驱动和固件层就更隐蔽了。服务器的BMC、加速卡固件、网卡固件这些更新通常没人管理由也很现实固件升级风险高稍有不慎就是整机离线运维宁可不动。可一旦固件层被攻破上层所有应用防护都等于白搭因为攻击者拿到的是比操作系统更底层的控制权。这个局面其实给漏洞治理提出一个根本问题在一个不透明的、多层的算力体系里怎么证明自己“没有漏洞”怎么保证每一次升级都不会引入新的坑我后来觉得要回答这个问题必须往下走一层先看算力底座本身有没有把信任的根基立住。这也是我和海光团队交流时他们反复强调的一个切入点。2. 为什么算力底座要把“可信根”当成第一道防线2.1 可信启动从第一条指令开始验证系统身份先讲一个很多团队容易忽略的概念可信启动。服务器的启动过程是一连串的执行链开机后先跑固件再引导操作系统内核再拉起容器和应用程序。老式方案里这条链上每一环默认都是“可信的”只要没中病毒就一直往前跑。可现代攻击者的手段之一就是直接改固件或者劫持启动引导让你“开机即中招”杀毒软件根本发现不了。可信启动的思路正好反过来链条最底部有一个硬件信任根通常是固化在芯片里的密钥和校验逻辑。从第一段代码开始每一层引导程序都要拿签名和度量结果去和信任根比对对不上就不继续加载。打个比方你进大楼不再是一张初始门禁卡刷到底而是每过一道门都要重新出示一次身份证明。这个底层逻辑决定了“补丁怎么打都还是稳的”。你说要升级固件可如果固件本身没有可信验证你怎么确定刷进去的镜像没有被篡改成恶意版本反过来有了可信启动固件升级自带校验升级的安全性边界才说得清楚。我之前在项目里最大的担忧就是“升级固件会不会把设备刷新成砖”可信机制解决了一部分这种不确定性。2.2 运行时加密与隔离假设别人已经进到系统里可信启动解决的是“开机过程不要被拉偏”但机器是7x24小时在跑的攻击面始终存在。所以第二步是运行时隔离和加密。我的理解里这个层面的核心原则是“零信任”假设攻击者已经拿到了某个进程、某个虚拟机的控制权我们的目标是把损害锁在笼子里而不是幻想攻击不会发生。硬件要提供的不只是一把万能锁而是几个互相独立的保险箱虚拟机之间做内存隔离进程之间做权限隔离敏感数据在内存中加密存放。这些能力如果用纯软件实现性能和安全性都要打折扣。硬件原生支持之后虚拟化隔离的开销可以降得很低密钥管理落在受保护的硬件区域内软件层即使被攻破也读不到真正的密钥。和海光团队交流时有一个说法让我印象很深安全能力要“默认开”不能指望用户跑到生产环境前再花三天读白皮书去打开某个开关。我后来在自己的项目里验证过凡是需要用户手动启用的安全项最后几乎都等于不存在因为总有环境会被漏配。2.3 从芯片向上做平台契约而不是往系统里塞补丁聊到安全底座这个话题最触动我的是他们对漏洞治理的定位不是安全部门手里的工具表而是算力平台和上层软件之间的一份“契约”。什么意思平台把可信启动、隔离、加密这些基础能力固定下来上层框架和应用只要遵守接口契约就能天然获得一部分安全收益不需要每家团队各自发明一套加固方案。漏洞治理因此从“追着补丁跑”变成“有边界的防守”基础层由厂商持续维护应用层由业务团队负责闭环两边各有清晰的责任边界。这其实也解释了为什么要把漏洞治理和算力底座统一来看。如果底层固件和驱动有漏洞应用层代码写得再安全攻击者还是能从地基打进地下室再顺着管道进到每一层。反过来底层基础打牢了应用层再去做漏洞治理才有明确的、可验证的起点。3. 漏洞治理实战链路从报告到闭环一个AI推理服务的完整复盘3.1 一次真实处置推理服务被报了一个“高风险”前面讲了很多理念层面的东西现在落到我实际负责过的一次处置案例上。当时我们有一套AI推理服务基于PyTorch训练模型再用开源推理框架对外提供API跑在海光服务器上。某天安全平台推送了一条漏洞通告推理框架依赖的一个公共组件存在高危任意代码执行漏洞CVSS评分很高而且公开PoC已经流出。我的第一反应不是立刻去升级组件而是先拉一张“资产-版本-暴露面”清单。这个习惯是从前几次踩坑里学出来的直接升级经常是为了修一个小洞把整套推理服务的依赖树全部破坏最后API响应时间涨了30%只能回滚白忙活一晚上。所以这次我决定先把情况摸清楚再说。3.2 影响面评估先别急着升级先回答“谁会被打穿”我先快速把漏洞影响面评估表填完关键在于回答三个问题漏洞存在于哪个环节谁能触达这个环节被攻破之后能往哪走当时的评估结论是这样的漏洞组件只在单个推理微服务中使用其他服务没有引用影响范围相对集中该微服务跑在内网对外只通过网关暴露网关有鉴权未认证流量无法直接触达推理接口但同一网络里还有训练平台一旦攻击者通过该漏洞突破推理服务可以进一步横向访问训练数据目录。所以评估结论是漏洞可利用但利用门槛较高需要先绕过网关鉴权真正的风险不是漏洞本身而是它和训练数据之间缺少一层隔离。于是我做的第一件事不是升级而是收紧推理服务到训练数据目录的访问权限改成独立分区隔离同时在网关加了一条WAF规则屏蔽可疑的序列化请求特征。这一步很关键它把紧急程度从“今晚必须升级”降级为“本周内完成升级但先把横向路径封堵掉”。漏洞治理真正考验的不是你会不会打补丁而是你能不能判断在什么时间、用什么顺序去动哪些系统。3.3 灰度修复与回归一条漏洞引发的三条检查项升级修复我没有直接在生产环境执行。我的做法是在测试环境把推理框架组件升级到安全版本然后跑三类回归。业务正确性回归用一批标注好的测试样本对比升级前后的模型输出。允许轻微数值波动但不允许出现明显的标签错乱。性能回归对比升级前后的单请求推理延迟、吞吐量以及算力卡利用率。框架升级导致算子重新编译是常有的事性能回退超过5%就要回头检查编译参数。安全回归再次扫描组件版本确认CVE对应的利用路径已经关闭再模拟一次序列化攻击请求确认WAF规则真实生效。全部通过之后我才在生产集群里挑了10%的节点灰度升级观察半天再扩展到全量。整个过程从评估到全量完成用了一周期间业务无感知。事后复盘我把几条固定检查项写进了团队规范每次升级框架必须同步更新SBOM软件物料清单、确认新的安全基线、重跑模型正确性用例。这三件事少做任何一件下一次升级就一定会有人踩坑。4. 算力厂商在漏洞协同上的“中间人”角色4.1 为什么厂商必须当“中间人”你可能觉得漏洞处理是自家团队的事和厂商有什么关系其实关系非常大尤其在算力侧的漏洞上。AI系统的算力底座包含CPU、加速卡、驱动、固件、管理控制器等多个层次每一层都可能有漏洞。但用户拿到的只是一块硬件和一套软件栈既没有固件源码也没有硬件设计文档。一旦漏洞通告出现用户根本无从判断这个漏洞对自己影响多大、升级固件之后会不会踩兼容坑。这时候算力厂商就是用户和底层技术细节之间的“中间人”。它需要做三件事把漏洞信息翻译成用户能执行的行动比如升级哪个版本、先做哪项加固提供能在用户环境里验证的补丁明确告诉用户哪些规避措施可以临时兜底而不是扔一个README让用户自己研究。4.2 公告、补丁、兼容矩阵协同机制的三个抓手和海光团队交流时我特别留意了他们对协同方式的描述。我把它总结成三个抓手。第一是安全公告的及时性。底层漏洞披露之后不能等媒体炒热才出来表态要在第一时间给出受影响版本范围和修复版本。用户不怕听到坏消息怕的是消息出了三天厂商还没动静只能靠猜。第二是补丁的验证成本。硬件厂商不像开源社区可以随便发补丁每个固件补丁都要在多种配置下做兼容性测试。所以厂商要给用户提供兼容矩阵哪些驱动版本、哪些操作系统、哪些上层框架搭配起来是被验证过的。用户照着这个矩阵配置最不容易踩雷。第三是临时缓解措施。有些生产环境不能马上停机升级厂商应该先给配置层面的缓解手段比如禁用某个协议、开启某项隔离参数让用户先把风险兜住再等维护窗口补正式补丁。这三个抓手表面是流程实际上是信任。用户敢不敢动生产环境取决于厂商有没有把这些信息做扎实。我在另一个项目里就遇到过一次底层固件需要跨三个大版本升级的情况要不是厂商给出了完整的兼容矩阵和回滚方案我绝对不敢在业务高峰期碰那个集群。4.3 我学到的“窗口缩短”经验还有一个让我印象特别深的概念漏洞治理的目标不是“尽快找到所有漏洞”而是“缩短从漏洞披露到系统恢复防护的时间窗口”。这个窗口越短攻击者趁虚而入的机会越小。为了缩短这个窗口我现在固定做三件事维护一份常用版本与安全联系人名单。漏洞通告一出来十分钟内就能确认是否影响我们使用的版本不用临时去翻官网。建立升级演练机制。在非生产环境预演关键升级步骤把常见失败原因提前踩一遍。真到了生产升级的时候心里有底动作就不会乱。把安全基线做成脚本和镜像而不是手工文档。跑一次扫描就能确认系统是否偏离基线而不是靠人肉对照配置清单。这三件事单独看都很小合在一起就是把“响应时间”从几天压到一天以内。漏洞治理最终不是某一个安全工具的问题它是一套“情报-决策-执行”的工程体系。5. 把硬件、框架、模型三层一起修的治理清单5.1 硬件、框架、模型三层责任的“安全责任制”到这里我发现自己之前对漏洞治理的理解确实有些偏窄。一个AI系统的安全至少要分成三层来看每一层的责任主体和动作都不一样。硬件层负责提供信任根、隔离、加密和可验证的安全启动漏洞由算力厂商持续修复用户的义务是及时跟随安全公告升级固件和驱动。框架层负责适配底层算力并提供运行时的安全接口漏洞通常来自开源社区或软件供应商用户需要建立SBOM清单持续跟踪依赖更新。模型层负责数据和模型文件本身的安全这块往往最被忽略。模型文件要校验签名训练数据要做来源审计推理输入要做内容过滤。很多团队做安全评审时压根不会把“模型输入”当作攻击面但这恰恰是AI系统独有的入口。这三层不能分开治理。硬件层不牢框架层再安全也可能被穿透框架层有洞模型层再干净也可能被横向攻击。比较务实的做法是画一张三层责任矩阵表每一层都明确负责人、检查频率和升级触发条件评审时对着表逐项过比临时凭感觉要靠谱得多。5.2 可以直接抄作业的四项制度把这套三层框架落地到日常我认为有四件事最值得先做。建立资产与SBOM台账把AI服务用到的硬件型号、驱动版本、框架版本、组件依赖、模型文件哈希都记录下来至少覆盖到“哪台机器跑哪个模型、依赖哪些组件”的粒度。没有台账漏洞治理就是大海捞针。制定漏洞分级响应时限高危漏洞要求24小时内完成影响面确认、72小时内给出修复计划中危按周处理低危进月度维护窗口。时限不是拍脑袋定的是根据团队人力、业务容忍度调整出来的定了就要考核。保持升级与回归基线每次升级动作都要配回归清单。框架升级至少跑正确性、性能、安全三类用例固件升级至少跑启动、资源监控、稳定性三类用例。升级不是把新版本安上就结束而是“安得上且不炸”才算完。做季度安全演练挑一个非核心集群人为模拟一次漏洞爆发从通告、评估、缓解到修复全流程走一遍。演练的价值不在于发现漏洞而在于把人与人之间的协作接口打通。真出事了谁负责通知、谁负责评估、谁负责执行、谁负责验证不需要现场商量。这几条都不复杂复杂的是坚持。我自己就是吃过亏才明白制度不是约束是救命绳。5.3 衡量漏洞治理成效的几个“笨指标”很多团队喜欢报“高危漏洞清零”这种指标我反而建议少用“清零”多用“收敛”。清零在AI系统里很难成立因为依赖链太复杂今天清了明天又来。真正要关注的是治理能力有没有在提升。我平时在跟踪的是四个指标漏洞平均发现到确认时长MTTD看情报监控灵不灵敏漏洞确认到修复时长MTTR看响应链路顺不顺关键节点覆盖率看核心资产有没有都纳入漏洞管理范围而不是只盯几台公网机器升级回归成功率看每次修复动作有没有引入新问题。这四个指标都不花哨但能真实反映治理水平。我记得某次复盘发现我们的MTTR特别长查来查去卡在了“等待厂商反馈”这个环节后来专门和厂商建立了直接的联系渠道时长一下就降了下来。这就说明指标的价值不在于好看而在于能暴露问题。这些经验说到底就是几个字把漏洞治理当成一个持续运转的工程而不是一次突击清扫。AI时代变化快、链路长、攻击面多但只要底座可信、链路清晰、响应迅速再多的漏洞也能接得住。最后分享一个感受。以前我总觉得“安全”是花架子是上线前突击准备一遍流程展示给别人看的。真连续处理过几次框架漏洞、固件漏洞之后我才理解为什么海光团队会反复强调“底座”两个字硬件可信、启动可控、隔离到位所有上层操作才有一个可以依赖的支点。如果你正被AI系统的漏洞清单搞得焦头烂额我建议你先别急着去补最外层花点时间看看自己的算力底座到底信不信得过。很多看似零散的漏洞最后都会追溯到同一个根源底层没有可信根上面所有安全动作都是悬空的。把这一层做实AI安全才算真正有了根基。