【学习笔记】探讨大模型应用安全建设系列5——供应链安全与数据防护

供应链安全在大模型场景里很容易被低估。很多团队以为管好代码依赖就够了但大模型应用的供应链比传统应用长得多——模型、Prompt、知识库、插件、外部 API 都是攻击面。LiteLLM 事件证明一个依赖包投毒短时间内就可能扩散到大量下游环境并导致环境变量、云凭证、API Key 等敏感信息暴露。这类风险不出事没人关心出了事往往就是系统性责任。这篇文章讲两件事供应链投毒怎么防数据防护怎么做——帮你回答领导我们的供应链安全吗这个问题。一、把链路拉长前面几篇更多关注应用运行时输入、输出、工具、权限。到了供应链和数据防护视角要往前后两端延伸模型从哪里来、Prompt 谁改过、知识库怎么进来、插件能做什么、RAG 检索出的内容是否该进入上下文。本文把视角从应用运行时扩展到更长的链路模型、依赖、Prompt、知识库、插件、外部 API 和 RAG 数据流都会影响大模型应用是否可控。二、LLM 供应链全景先看清楚你的供应链有多长环节资产类型污染后果基础模型模型权重/服务后门、偏见、能力边界被改变Embedding 模型向量化能力检索结果被操纵Prompt 模板系统提示/任务模板安全策略被改写向量库/知识库RAG 检索源虚假信息注入插件/技能包Agent 工具能力恶意代码执行、数据外泄外部 API工具调用目标返回值被注入恶意指令评测集安全测试基准安全评估被操纵训练数据模型学习源模型学到错误模式只审代码仓库已经不够了。安全评审必须覆盖模型、数据和工具的组合关系。三、真实案例LiteLLM 供应链投毒事件2026 年 3 月这是迄今为止影响最大的 AI 中间件供应链攻击事件。3.1 时间线2026-03-19攻击者改写 Trivy GitHub Action tag为先导入口2026-03-24 10:39litellm 1.82.7 发布到 PyPIproxy 模块导入触发2026-03-24 10:52litellm 1.82.8 发布到 PyPI.pth 启动钩子触发安装即触发2026-03-24 11:25PyPI 在约 46 分钟内隔离两个恶意版本3.2 影响范围攻击窗口内两个版本合计下载约46,996 次litellm 月下载量约 9,600 万级PyPI 上2,337 个包直接依赖 litellm其中88%2,054 个的版本约束会解析到受影响版本3.3 攻击技术三阶段载荷阶段一凭证搜集环境变量、SSH/Git 凭证、云凭证含 IMDS 元数据Kubernetes token/Secret、.env、数据库配置、shell history阶段二加密外传AES 加密数据 RSA 加密会话密钥打包为tpcp.tar.gz外传至models.litellm.cloud同时轮询checkmarx.zone/raw获取后续指令阶段三持久化与横向移动主机侧写入~/.config/sysmon/sysmon.py创建 systemd user service伪装为System Telemetry ServiceK8s 场景在 kube-system 创建特权 Pod挂载宿主盘3.4 关键弱点这起事件与 SolarWinds、event-stream、xz backdoor 有共同特征均利用信任链而非传统漏洞偏好高杠杆节点。弱点说明CI/CD tag 漂移依赖的 tag 被改写指向恶意版本发布 token 暴露长生命周期 token 在 Runner 环境中暴露缺乏 OIDC Trusted Publishing没有用身份绑定验证发布者下游依赖约束过宽88% 的依赖包没有上界约束hash 校验无效合法发布但内容恶意的构件无法被 hash 检测四、Agent 技能包投毒另一种供应链攻击当你的 Agent 可以安装技能包Skills/Plugins时供应链攻击面又多了一层。4.1 恶意技能包主要有 7 种攻击模式1.工具投毒技能包说明中的隐蔽指令改变 Agent 决策边界2.远程指令加载不直接放恶意代码从外部站点动态获取3.数据窃取读取本地敏感文件、凭据、浏览器数据并上传4.提示注入用 Unicode、零宽字符等方式在技能包文本中夹带隐藏内容5.资源耗尽诱导 Agent 陷入高成本推理/工具循环6.记忆污染写入持久化文件让恶意指令跨会话长期存活7.供应链冒充近似命名、拼写变体、假冒热门技能4.2 隐藏注释攻击的真实验证一个特别值得关注的攻击方式是隐藏注释投毒实验在 DeepSeek-V3.2 与 GLM-4.5-Air 上验证。投毒版技能包在末尾追加 HTML 注释指挥模型做三类敏感动作枚举环境变量、读取凭证文件、发起 HTTP 请求用于外带。关键在于HTML 注释在页面上不可见人类审核不到但系统把原始文本喂给模型时这些不可见内容仍然会进入上下文——人看不见、模型看得见的指令盲区。五、数据防护RAG 场景的六个阶段RAG检索增强生成是企业用大模型最常见的场景也是数据泄露风险最高的场景之一。5.1 RAG 安全的风险链分为六个阶段阶段风险防护要点1. 语料接入不可信文档、恶意网页被接入知识源来源验证、内容审核2. 知识库存储敏感信息、未分级数据直接混入数据分级、权限标签3. 向量索引缺少租户隔离、权限标签租户隔离、访问控制4. 检索匹配带操纵性内容被高相关召回权限过滤、相关性验证5. Prompt 融合检索结果被当成应服从的指令文本身份区分6. 输出/执行模型泄露敏感内容输出检测、脱敏5.2 RAG 权限控制的三个关键点1. 检索层必须做权限过滤一个用户没有权限看的文档不应该因为向量相似度高就被放进上下文。检索层是实现数据权限的最后一道门——过了这层数据就进了模型的视野你很难再控制它会被怎么加工和输出。2. 上下文组装必须做分级进入上下文的内容需要明确标记哪些是系统指令不可覆盖、哪些是用户输入表达任务、哪些是检索资料提供事实、哪些是工具返回值作为结果。不同身份的文本有不同的权限边界。3. 输出必须做敏感信息检测模型不只是原样泄露数据它还能把多段低敏信息拼成高敏结论。这种语义泄露比原文泄露更难被传统 DLP 规则捕捉。安全负责人行动项要求你的团队在一个月内完成供应链资产盘点——至少回答四个问题线上用的什么模型版本Prompt 模板谁改过向量库内容来自哪里插件权限经过谁批准五、供应链安全 Checklist把以上内容整合成一份可操作的检查清单5.1 模型/工具层[ ] 基础模型是否有版本管理和来源记录[ ] 使用的开源模型是否经过安全审计[ ] 插件/技能包是否经过审查才允许安装[ ] Prompt 模板是否有版本控制和变更审计[ ] 技能包文本是否做了不可见字符/HTML 注释清理5.2 依赖管理层[ ] Python/Node 依赖是否有上界约束[ ] 是否使用了 hash 校验或 OIDC Trusted Publishing[ ] CI/CD 的发布 token 是否有短期轮换机制[ ] 是否有自动化的依赖漏洞扫描5.3 数据层[ ] 知识库内容是否按权限分级[ ] RAG 检索层是否做了用户级别的权限过滤[ ] 向量库是否有租户隔离[ ] 输出是否经过敏感信息检测5.4 运营层[ ] 能否回答当前线上使用的模型版本是什么[ ] 能否回答Prompt 模板谁改过[ ] 能否回答向量库内容来自哪里[ ] 能否回答插件权限经过谁批准六、小结大模型应用的供应链比传统应用更长、更隐蔽、更难管。用资产清单覆盖模型/数据/工具/模板/评测集的全链条从 LiteLLM 事件中学到依赖约束要加上界、CI/CD 要用 Trusted Publishing、hash 校验不够从技能包投毒中学到安装前要审查、不可见字符要清理、技能包不能自动获得高权限RAG 场景检索层做权限过滤、上下文做分级、输出做敏感检测下一篇我们进入合规——在国内做 AI 应用备案、标识、审计怎么一条龙搞定。汇报要点向领导汇报供应链安全时重点说我们已掌握全链路资产清单关键依赖有监控和变更审计——证明供应链风险在可控范围内。参考资料1、https://mp.weixin.qq.com/s/X03sZO_V21saFrV9iYzbkw