供应链

• 资料来源：genai.owasp.org
• 资料整理：韦胖

是什么意思？

构建 AI 应用不只是调用一个模型那么简单，背后涉及一整条"供应链"：训练数据从哪来？用了哪些第三方模型？依赖了什么开源库？部署在哪个平台？这整条链路上的任何一个环节，都可能成为攻击的入口。

这就像食品安全——问题可能出在原材料、加工环节或运输过程的任何一处。相比传统软件，AI 供应链的特殊之处在于还要考虑预训练模型和外部数据集的安全性。Hugging Face 等平台上大量开放模型的流行，以及 LoRA（低秩适应）等微调技术的兴起，让供应链的攻击面大幅扩大。

常见风险

1. 用了过时的组件：依赖久未更新、已有已知漏洞的第三方库或工具，攻击者可直接利用这些漏洞入侵。

2. 许可证风险：AI 开发用到的代码和数据集如果许可证管理不当，可能引发法律纠纷，比如商业用了只允许研究用途的数据集。

3. 用了停止维护的模型：继续使用已不再维护的模型，意味着它的安全问题永远不会被修复。

4. 使用了被"埋雷"的预训练模型：有些公开模型可能已经被植入偏见或后门，通过数据投毒或直接篡改模型权重（如 ROME 技术）完成，外表看不出任何异常。

5. 无法确认模型来源：现有的模型发布流程缺乏可靠的溯源机制，模型卡只是文档，不能证明模型没有被篡改。攻击者可以以此实施社会工程攻击。

6. 被污染的 LoRA 适配器：LoRA 微调让模型更灵活，但也带来了新风险——如果使用了被恶意修改的 LoRA 适配器，模型的行为就会悄悄出问题。

7. 协作开发流程被利用：模型合并、格式转换等协作服务可能被攻击者利用，在过程中悄悄植入漏洞。

8. 设备端 AI 的供应链风险：在手机、物联网设备上运行的 AI 模型，可能在生产制造或固件更新环节被篡改。

9. 模糊的数据隐私条款：使用条款不清晰的第三方服务，可能在你不知情的情况下把用户数据用于模型训练，增加数据泄露风险。

如何防范

1. 严格审查供应商：仔细阅读供应商的服务条款和隐私政策，只用可信来源，定期重新评估。
2. 管理组件漏洞：参照 OWASP A06（易受攻击的过时组件）做好漏洞扫描，及时更新依赖。
3. 测试第三方模型：使用前通过 AI 红队测试评估安全性，参考 Decoding Trust 等可信基准进行验证。
4. 维护软件物料清单（SBOM）：记录所有用到的组件，方便追踪和排查篡改。可以使用 OWASP CycloneDX 等工具。
5. 管理 AI 许可证：建立许可证清单，定期审计，确保使用方式符合许可条款。
6. 验证模型完整性：使用有明确来源的模型，结合文件哈希和数字签名验证其完整性，防止被替换或篡改。
7. 监控协作开发环境：对模型合并、格式转换等操作实施严格的审计，可使用 HuggingFace SF_Convertbot Scanner 等自动化工具。
8. 对数据和模型做异常检测：持续检测训练数据和模型行为是否存在异常，增强对对抗性攻击的抵抗能力。
9. 及时打补丁：保持 API 和底层模型使用受支持的维护版本。
10. 给设备端模型加密：对运行在边缘设备上的模型进行加密，防止被篡改或提取。

真实攻击场景

场景 1：依赖库漏洞

攻击者利用某 AI 应用依赖的 Python 库中的漏洞，成功入侵系统（类似 OpenAI 早期数据泄露事件）。

场景 2：直接篡改并发布模型

攻击者修改模型并上传至 Hugging Face，绕过安全机制传播虚假信息（类似 PoisonGPT 案例）。

场景 3：微调模型藏后门

攻击者微调了一个开放模型，使其在特定领域表现良好，但在特定触发条件下会执行恶意操作。

场景 4：使用未验证的预训练模型

开发者直接使用网上下载的预训练模型，未经验证，结果模型在特定情境下输出带有偏见或有害的内容。

场景 5：LoRA 适配器被篡改

攻击者修改了第三方提供的 LoRA 适配器并提交给开发者，合并进模型后引入了隐蔽的漏洞。

场景 6：渗透供应商

攻击者入侵供应商系统，篡改 LoRA 适配器，在模型中植入后门，实现对下游应用的隐蔽控制。

场景 7：云端共享资源攻击

攻击者利用云平台的虚拟化漏洞，通过共享资源攻击同一平台上运行的 AI 服务，危害关键部署环境。