最近和海光的安全团队做了一次技术交流话题聚焦在“AI时代的漏洞治理”。聊完之后我最大的感受是大模型把安全问题的边界推得越来越大传统的漏洞修补思路已经不够用了。过去我们谈漏洞治理主要集中在操作系统、中间件、应用代码现在则要一路下沉到CPU、DCU算力芯片、固件、驱动、容器镜像、模型权重文件甚至推理过程中的提示词和数据通道。任何一个环节失守都可能让整个AI系统“带病运行”。这篇文章就把这次交流的核心内容梳理出来重点讲透三件事AI安全底座到底包含哪些层、海光这类算力芯片厂商在漏洞治理上踩过哪些坑、以及我们在实际部署AI基础设施时应该用什么样的流程去排查和修复漏洞。不管你是做AI平台运维、安全测试还是对算力芯片安全机制感兴趣这篇内容都能直接落地参考。1. 对话开场AI越大安全底座越不能塌1.1 漏洞治理凭什么成了AI时代的“地基工程”先抛一个真实的场景。一套大模型推理集群表面上看跑得挺稳API响应正常QPS达标GPU或DCU利用率漂亮。但一次安全巡检下来问题清单长得吓人某个推理节点的BIOS两年没更新微码版本存在已公开的侧信道漏洞容器镜像里躺着一个CVSS 9.8的底层库漏洞模型推理服务的管理接口裸奔在内网没有鉴权连日志系统都没有记录谁调用过模型、喂进去过什么数据。这不是虚构而是很多AI团队的真实状态。AI系统的架构天然是分层的底座是算力芯片和服务器上面是操作系统和虚拟化层再往上是容器编排、AI框架、模型服务最外层才是各类应用和智能体。以前做安全测试大家习惯盯着最外层的Web接口、API权限、数据脱敏但AI时代最危险的反而是底层。因为大模型对算力的依赖几乎是无限的芯片、固件、驱动一旦出问题影响面就是整片集群。这也解释了为什么我会对海光这类算力厂商的漏洞治理思路特别感兴趣。芯片不是“焊死在主板上就完事”的硬件它内部有微码、有安全协处理器、有固件、有驱动接口甚至有自己的内存加密机制。这些组件每一个都有攻击面。海光安全团队这次交流中反复强调一个观点算力芯片的漏洞治理必须前置到设计阶段而不是等出货后再打补丁。1.2 对话中的核心分歧漏洞治理到底该治什么交流中我抛出一个问题你们对外做漏洞响应报得最多的漏洞集中在哪些层海光工程师的回答很有意思他说漏洞报告来源分三类一是芯片微码和固件层面的硬件漏洞数量少但危害巨大二是驱动和系统软件层面的兼容性与权限漏洞占了日常响应的大头三是生态链上第三方组件引入的风险比如BIOS厂家、整机厂商、OS厂商的安全公告同步。这三类问题单纯靠安全团队自己盯是不够的必须靠一套协同机制才能形成闭环。这和传统软件漏洞治理的本质差别在于一个漏洞从被公开到真正影响最终用户中间隔了太多的环节。比如微码漏洞芯片厂商要先出修复微码然后主板厂商要集成到BIOS更新里接着OS厂商要推送更新最后是运维团队评估升级窗口。任何一个环节卡住漏洞就始终处于“已公开但未修复”的裸奔状态。所以海光内部有一个原则叫“安全公告不过夜”意思是漏洞评估结论出来后必须第一时间同步给整机和OS伙伴而不是捂着等发布时间。这个对话启发了我真正合格的AI安全底座不是靠某一个安全产品而是靠整条链路都能快速联动。下面我就按算力层、漏洞闭环、AI场景、实操排查四个维度把这次交流中的干货拆开讲。2. 算力层漏洞治理芯片、固件、驱动最容易“裸奔”的三层2.1 芯片漏洞的三种常见形态与排查思路很多人一听到芯片漏洞第一反应是“熔毁”“幽灵”这类侧信道攻击。这类漏洞确实存在而且在新一代处理器中仍有变种但真实运维中芯片层漏洞远不止这一种形态。我按实际遇到的情况把芯片漏洞归成三类方便对照排查。第一类是微码逻辑漏洞。这类问题影响面最大比如CPU在某些边界条件下的异常行为可能导致权限绕过或系统崩溃。修复方式通常是一个微码更新包通过BIOS升级或OS的微码加载机制来应用。排查思路很简单定期核对当前CPU微码版本与厂商安全公告中推荐的版本是否有差距。第二类是安全协处理器固件漏洞。现代处理器内部基本都有独立的“安全处理器”负责启动校验、密钥管理、内存加密等工作。这块固件一旦出漏洞相当于整个可信根被人挖了墙角。这类漏洞不一定那么好感知因为系统本身还能正常运行但如果你发现安全启动经常校验失败或者内存加密功能异常就要往这个方向查。第三类是并发工程状态问题比如不同线程或不同算力单元之间共享资源时出现的侧信道风险。这类漏洞在AI推理密集场景中被利用的概率更高因为推理任务往往长时间、高并发地共享缓存和算力单元。缓解思路包括刷新缓存、限制共用资源、更新微码等等。实操中最有效的还是升级微码不要在旧版本上反复试探。海光同行提到一个很关键的机制他们会用公开的漏洞情报加自己的攻击面梳理形成一张“算力漏洞地图”把每个芯片型号支持的指令集、虚拟化特性、内存加密机制、安全启动链全部列出来再和漏洞库做关联匹配。这比单纯等安全公告要靠谱得多。我们自己落地时也可以参考给每台服务器建一份“算力资产清单”记录CPU/DCU型号、微码版本、BIOS版本、驱动版本定期比对厂商安全公告。2.2 固件升级和安全启动的实操路径固件升级这块很多人容易犯一个低级错误直接在操作系统内跑厂商的刷新工具却忽略了两件事——当前固件版本和升级包是否匹配以及安全启动Secure Boot是否处于正常状态。以海光平台为例固件升级的标准路径一般是这样先确认当前BIOS版本和EC版本。在Linux下可以执行 dmidecode -t bios 获取在Windows下可以用 msinfo32或者直接看系统信息里的BIOS版本。记录下完整版本号而不是只看日期。从整机厂商或主板厂商官网下载匹配的固件包。这里要特别提醒算力服务器务必以整机厂商发布的固件为准不要随意刷公版BIOS否则可能丢失整机厂商的硬件配置和功耗调优。在维护窗口内执行更新。多数平台支持在操作系统中运行工具例如海光的Linux下刷固件工具或Windows下的刷新工具。有的服务器需要先写入BMC再通过重启触发更新。更新完成后要重新检查安全启动状态。进BIOS确认Secure Boot处于开启并确认系统已正确导入新的Platform Key。很多AI硬件节点为了快速部署安全启动其实一直被关着这相当于把固件的完整性校验整个关闭了。最后在OS层升级相关驱动。驱动版本和固件版本往往存在配套关系固件升级后驱动不升级可能出现性能不达预期甚至设备无法识别的情况。可以用 lspci -vvv 或者Windows设备管理器检查设备状态和驱动日期。这里我额外补充一条排查技巧如果固件升级后系统提示“安全启动证书无效”或者“安全验证失败”多数情况不是安全启动本身坏了而是BIOS的DB合法签名数据库里缺少新固件对应的证书。解决办法是先从厂商官网下载证书文件再导入到BIOS的Key Management中。有些场景下也可以在OS里安装证书更新包Windows 11用户经常遇到的“安全启动证书更新”问题就是这类原因。3. 漏洞全生命周期治理从发现、上报到修复的闭环3.1 漏洞优先级排序不能只看CVSS分数在交流中海光安全团队提了一个观点我非常认同CVSS分数只能作为入门参考真正决定修复优先级的是漏洞在你的实际环境中能不能被触发。举个例子某个芯片微码漏洞的CVSS Base Score是7.5看起来不高但它碰巧影响你正在用的虚拟化方案且攻击者在虚拟机内可触发那它的实际风险就远高于一个CVSS 9.0但只在特定指令集组合下才会出现的漏洞。所以我们自己做漏洞治理时会建立一个“环境加权”的评价体系资产重要性这台服务器是跑训练还是推理是否承载核心业务模型攻击可达性漏洞影响组件是否对外暴露攻击者能否在无需特殊权限的情况下触发缓解措施覆盖情况是否已经有其他机制兜底例如内存加密、容器隔离、网络ACL修复成本升级固件是否需要长停机窗口是否有兼容性风险把这四个维度综合起来再决定修复窗口是一周内还是一个月内。这样既能避免“漏洞逼迫式升级”导致业务中断也能防止低优先级漏洞被长期搁置。3.2 SBOM与供应链漏洞排查自己几斤几两要心里有数AI基础设施的软件供应链复杂度非常高一个推理服务镜像里可能包含基础OS、CUDA或ROCm生态依赖、Python库、AI框架、模型推理引擎、以及各种安全代理。任何一个依赖项出现漏洞整个系统都可能被标记为“带病运行”。海光在这次交流中也提到了他们的做法内部有一套SBOM软件物料清单管理机制每台服务器从出货时的固件、驱动到预装OS和安全组件全部生成可审计的清单。这样在出现新漏洞时可以快速定位“哪些客户、哪些型号、哪些版本受影响”。这个思路放到任何AI团队都成立。实操上我建议三步走用工具生成现有系统的SBOM。容器镜像可以用 trivy、syft 这类工具扫描和导出主机层面的软件包可以用系统包管理器的导出功能也算一个基础版本。定期做“漏洞情报交叉比对”。把SBOM中的组件名称和版本与公开漏洞库做匹配。重点检查固件微码、GPU/DCU驱动、内核、容器运行时这几个关键组件。建立最小可复现的升级验证流程。每次升级固件或驱动前准备一台测试机跑一轮完整的推理性能和稳定性测试再批量推广。别拿生产集群当小白鼠。这部分我有一个非常心疼的踩坑经历曾有一套AI推理集群因为长期不更新内核版本太老导致DCU驱动无法适配结果在升级驱动时被迫连OS一起升级直接多花了两个通宵的迁移时间。早知如此当初就该把固件、驱动、内核、安全补丁一起纳入版本基线管理而不是今天补一个、明天补一个。4. AI推理与训练场景下的安全风险盘点4.1 模型安全提示注入、数据投毒与输出验证聊完算力层和系统层再看AI应用层的安全问题。这次交流中海光安全团队特意提醒了一件事算力平台安全做得再好也扛不住模型本身被投毒。现在的AI安全测试中有几个方向几乎绕不开提示注入攻击、模型数据投毒、训练数据漂移、输出内容异常。比如一套企业客服大模型攻击者可能伪装成普通用户在对话里嵌一段恶意指令让模型泄露系统提示词或者在生成的代码和文案中植入有害内容。更隐蔽的是数据投毒训练数据被人掺入特定样本模型在特定条件下就会输出攻击者预期的结果。模型侧的安全治理没有银弹但有几条底线值得守住输入侧做意图审计对调用模型的请求做风险标注尤其是低权限用户能触发的系统级指令。输出侧做合规过滤模型输出必须经过一层校验不能直接透传。模型文件做完整性校验发布模型权重时附带校验哈希加载模型时校验文件签名防止模型被替换。数据管道做溯源训练数据的来源、清洗过程、标注版本都应有记录一旦出现异常输出能回溯到具体数据批次。4.2 算力资源的安全边界与日志审计AI平台还有一个安全问题容易被忽视算力资源本身变成了攻击者的“挖矿工具”或者“跳板”。如果你的推理服务管理接口没有鉴权任何人都可以提交大模型任务那就等于免费给陌生人提供算力。更严重的攻击者能通过模型接口渗透到底层容器读走其他租户的数据。所以算力平台的安全边界至少要收拢到三个位置管理面推理集群的管理接口、Dashboard、API网关必须启用鉴权至少做到口令强认证加访问控制。不少团队为了方便把所有节点都放在一个大网段里管理口和业务口不隔离这是最危险的做法。资源面GPU/DCU的显存、内存、算力调度要隔离。容器场景里建议开启设备隔离机制不要让非授权容器直接访问物理设备的全部显存。数据面模型输入输出数据要有日志留痕。虽然大模型日志里可能包含敏感信息但完全不打日志就没法做安全审计。合理的做法是对日志做脱敏存储保留必要的调用链信息删除正文内容。海光同行在交流中说了一句话我觉得特别到位“安全底座不只是防黑客的还要防自己人误操作。”很多AI平台事故其实不是外部攻击引起的而是内部一条错误的命令、一次未验证的配置变更把整个集群的安全状态破坏了。所以日志审计不只是为了溯源更是为了每次变更后有据可查。5. 常见问题与排查技巧实录5.1 AI环境部署中高频安全报错处理速查整理一下在AI基础设施部署和漏洞治理过程中我最常遇到的几类问题以及对应的排查思路。现象可能原因优先级排查建议安全启动证书更新失败系统时间不对、DB证书链缺失、固件版本过低高先校时再从固件厂商下载证书包导入BIOS最后考虑OS补丁固件升级后DCU/GPU驱动失效固件与驱动版本不配套、PCIe设备ID变化高回退到配套驱动版本或升级到官方最新配套驱动微码版本长期不更新没有关注厂商安全公告、BIOS未内置新微码高建立微码版本台账每季度比对一次容器镜像漏洞扫描结果太多基础镜像太旧、依赖库版本滞后中切换精简基础镜像配合trivy扫描结果逐项修复推理服务接口被异常调用管理接口未鉴权、白名单缺失紧急关闭公网暴露启用IP白名单和鉴权训练任务出现非预期输出下降数据管道被投毒、模型权重被篡改紧急校验模型哈希回溯数据批次来源内存加密功能不可用BIOS未开启、固件不支持、虚拟化层未透传中检查BIOS开关和OS日志中的TSM错误这张表不是标准答案而是给出一条排查路径。真实环境中的问题往往交织在一起别指望一条命令解决要按链路逐层排除。5.2 排查思路从日志、证书、版本三个维度入手遇到AI环境安全类报错时我的排查习惯是先抓三类信息日志、证书、版本。日志是第一现场。凡是和安全启动、固件、驱动相关的报错先看系统事件日志。Linux下查看 dmesg 里有没有 TPM、Secure Boot、ME、firmware相关的报错Windows下查看事件查看器中的“系统”日志筛“Kernel-Power”“Secure Boot”“TPM”来源。日志里通常会有明确的错误码比网上搜索关键词要可靠得多。证书是安全启动类问题的关键。如果报错提示“Secure Boot验证失败”那就进BIOS的Secure Boot菜单查看当前Secure Boot状态和证书库里是否有合法的平台密钥。有些AI服务器为了兼容旧系统会把安全启动关闭这时就要权衡是优先兼容旧环境还是优先安全合规。我的建议是生产环境必须开启安全启动宁可多花点时间解决兼容性问题。版本是最后一道防线。固件、微码、驱动、OS内核、AI框架这五层的版本必须形成一个“经过验证的组合”。很多漏洞不是没法修而是修了A没配套升级B导致系统进入一个更不稳定的状态。建议每季度做一次版本基线的整体复核而不是临时抱佛脚。还有一个细节Windows下如果开启了安全中心某些驱动安装会被“受信任的平台模块”策略拦下来。很多运维误以为关闭安全中心就能解决其实这只是掩盖问题。正确的做法是确认驱动是否通过了签名认证如果驱动本身没问题就更新系统补丁或安全启动证书库而不是绕过去。绕一时爽后面漏洞爆发的时候就会很被动。最后分享一条个人经验我在给AI推理集群做安全加固时坚持把“安全基线检查”做成每个月固定动作哪怕只是跑一遍脚本输出一份报告。这份报告不一定每次都有大问题但它能逼着团队去关注固件版本、微码状态、驱动配套、证书有效性这些最容易被遗忘的底层细节。时间长了漏洞治理就会从“救火”变成“防火”。说到底AI安全底座这件事没有一劳永逸的方案只有不断维护的动态平衡。算力芯片厂商能做的是提供可信的硬件根、及时的漏洞公告、畅通的修复通道而我们这些使用者要做的是把漏洞治理落实成一套周而复始、从不间断的流程。两条腿一起走AI时代的安全底座才算真正筑牢。