# 8.6 供应链与基础设施环境安全

LLM 应用依赖复杂的供应链，包括模型、数据、库和服务。供应链中的任何环节被攻击都可能影响整体安全。

## 8.6.1 LLM 供应链概述

LLM 应用的供应链比传统软件更加复杂：

```mermaid
flowchart TB
    subgraph "LLM 供应链"
    A["预训练模型"] --> E["目标应用"]
    B["微调数据集"] --> E
    C["开源库/框架"] --> E
    D["第三方服务"] --> E
    F["插件/扩展"] --> E
    G["嵌入模型"] --> E
    end
```

图 8-27：LLM 供应链组成流程图

## 8.6.2 供应链风险类型

**被污染的预训练模型**

```
风险场景：
- 从非官方渠道下载模型
- 模型已被植入后门
- 使用时表面正常
- 特定触发条件下执行恶意行为
```

**恶意数据集**

```
风险场景：
- 使用公开的微调数据集
- 数据集中包含投毒样本
- 微调后模型行为被改变
```

**依赖库漏洞**

| 风险类型 | 描述          |
| ---- | ----------- |
| 已知漏洞 | 使用有已知漏洞的库版本 |
| 依赖混淆 | 下载了恶意的同名包   |
| 恶意更新 | 正常库被恶意更新    |
| 废弃依赖 | 使用不再维护的库    |

**第三方服务风险**

```mermaid
flowchart LR
    A["LLM 应用"] --> B["嵌入服务 API"]
    A --> C["向量数据库服务"]
    A --> D["第三方工具 API"]

    B -.-> |服务被攻击| E["风险传导"]
    C -.-> |数据泄露| E
    D -.-> |恶意响应| E
```

图 8-28：第三方服务风险传导流程图

## 8.6.3 模型供应链安全

**可信来源的重要性**

```
安全来源：
✓ 官方模型仓库（平台认证账号）
✓ 知名机构发布的模型
✓ 有完整审计记录的模型

风险来源：
✗ 来源不明的模型文件
✗ 非官方的“优化版”模型
✗ 未经验证的社区上传
```

**模型验证措施**

| 措施   | 描述        |
| ---- | --------- |
| 哈希校验 | 验证模型文件完整性 |
| 签名验证 | 确认发布者身份   |
| 后门扫描 | 检测潜在的后门行为 |
| 行为测试 | 验证模型行为正常  |

> \[!TIP] 开源工具参考：[ModelScan](https://github.com/protectai/modelscan) 可扫描 `.pkl`、`.h5`、`.pb` 等模型文件中的 `unsafe code` 与模型序列化攻击风险；[Safetensors](https://github.com/huggingface/safetensors) 是 Hugging Face 推出的安全序列化格式，从根本上避免了 Pickle 反序列化带来的任意代码执行风险，建议优先使用。

## 8.6.4 依赖管理安全

**Python 生态风险**

```bash

# 风险示例：不安全的依赖安装
# 可能安装恶意包
pip install some-package  # 包名可能被抢注

# 安全做法：requirements.txt 中锁版本和哈希
package==1.2.3 --hash=sha256:<真实哈希>

# 安装时启用 hash-checking mode
pip install --require-hashes -r requirements.txt
```

**依赖安全最佳实践**

```mermaid
flowchart TB
    A["依赖声明"] --> B["版本锁定"]
    B --> C["漏洞扫描"]
    C --> D["许可证审查"]
    D --> E["定期更新"]
    E --> F["安全审计"]
```

图 8-29：依赖安全管理流程图

**工具推荐**

| 工具          | 功能               |
| ----------- | ---------------- |
| pip-audit   | Python 依赖漏洞扫描    |
| Snyk        | 多语言依赖安全          |
| Trivy/Grype | 容器、文件系统与开源组件漏洞扫描 |
| Syft        | 软件物料清单 (SBOM) 生成 |
| Dependabot  | 自动依赖更新           |
| Gitleaks    | 扫描代码与配置中的凭证/密钥泄露 |

## 8.6.5 插件与扩展安全

LLM 应用常通过插件扩展功能，这也引入风险。

### 插件风险

```
风险类型：
1. 恶意插件：专门设计的攻击性插件
2. 漏洞插件：正常插件中存在漏洞
3. 权限过度：插件请求超出需要的权限
4. 数据泄露：插件将数据发送到外部
```

### 插件安全框架

```mermaid
flowchart TB
    subgraph "插件安全"
    A["来源验证"] --> B["代码审查"]
    B --> C["权限控制"]
    C --> D["沙箱隔离"]
    D --> E["行为监控"]
    end
```

图 8-30：插件安全框架图

### Agent 插件的供应链完整性保证：SLSA + Sigstore

对于 Agent 生态中的插件、连接器和工具分发，传统的 SBOM 清单还不够——需要从根本上保证 **构建过程本身的完整性** 和 **工件发布者身份的真实性**。这正是 **SLSA（Supply-chain Levels for Software Artifacts）** 框架 + **Sigstore 无密钥签名** 的核心价值。

**SLSA 框架在 Agent 插件中的应用**

SLSA 的旧版与新版在等级表述上存在差异。当前稳定的 `SLSA v1.x` 主要定义了 Build Levels `1-3`；早期 `v0.1` 文档里则出现过 `0-4` 的写法。工程上应避免把二者混成一张静态表来引用。

| SLSA 等级     | 构建要求        | Agent 插件适用性        |
| ----------- | ----------- | ------------------ |
| **Level 1** | 基础构建可追踪     | 源码与构建来源可被记录        |
| **Level 2** | 托管构建环境      | 使用受控 CI/CD，而不是本地发布 |
| **Level 3** | 更强的来源与完整性保证 | 强化审查、来源证明与构建完整性    |

**具体实施路径**

```
Agent 插件发行流水线示例（SLSA L2）：

1. 开发者提交代码到主分支
2. GitHub Actions 自动触发构建
3. 构建系统生成工件（.zip / .tar.gz）并计算哈希
4. 构建日志记录在 GitHub 中（不可篡改）
5. 发布前：自动运行单元测试 + 安全扫描（SAST）
6. 若测试通过：自动生成带哈希的 SLSA provenance 文件
7. 将工件和 provenance 发布到 registry（PyPI/npm/artifact registry）
```

**Sigstore 无密钥签名的关键优势**

传统数字签名需要管理长期密钥，容易因密钥泄露导致下游应用被污染。Sigstore 通过 **keyless signing** 解决了这一难题：

```
传统方式：
开发者 ──(拥有私钥)→ 签署工件 ──→ 用户验证签名

Sigstore 方式：
开发者 ──(通过 OIDC 连接)→ Fulcio 短期证书
              ↓
         用 Cosign 签署工件（证书+签名）
              ↓
         工件 + 签名发布到 Rekor 透明日志
              ↓
用户 ──(离线验证)→ 检查 Rekor 日志 + 验证签名一致性
```

**Sigstore 核心组件**

1. **Fulcio**：无状态 CA，基于 OIDC（如 GitHub、Google 账号）颁发短期证书（有效期约 10 分钟）
2. **Cosign**：签署和验证工件的命令行工具，支持 OCI 镜像和任意文件
3. **Rekor**：不可篡改的公开透明日志，记录所有签名事件（可用于审计和回滚）

**Plugin Registry 的最小实施要求**

```
# 发布插件时的强制检查清单
✓ 工件哈希（SHA-256）必须与 SLSA provenance 中的哈希一致
✓ 签名必须通过 Sigstore 验证（Cosign verify）
✓ 构建 provenance 必须来自 GitHub Actions（可信构建环境）
✓ 代码审查日志必须在 provenance 中标注
```

**防御效果**

* 即使攻击者截获了发布凭证，由于短期证书限制，也无法伪造过去的签名
* 用户可通过 Rekor 审计日志追踪所有发布历史，检测异常发行
* 离线验证意味着用户无需依赖 PKI 基础设施，降低了对中心化信任的依赖

## 8.6.6 软件物料清单

SBOM 帮助组织了解其软件的组成成分。

**SBOM 内容**

```
LLM 应用 SBOM 示例：

核心模型：
- 模型名称：某开源模型
- 来源：官方或认证发布者
- 版本：发布版本号
- 许可证：对应开源许可证

依赖库：
- 依赖名称与版本锁定
- 哈希/签名（如支持）
...

第三方服务：
- 嵌入服务：某嵌入 API
- 向量数据库：某向量数据库服务
...
```

**SBOM 价值**

* 快速识别受影响组件
* 满足合规要求
* 支持漏洞响应
* 供应链透明度

## 8.6.7 供应链安全策略

**预防措施**

```
1. 建立可信供应商清单
2. 实施依赖版本锁定
3. 定期漏洞扫描
4. 模型和数据来源验证
5. 第三方服务安全评估
```

**检测措施**

```
1. 持续监控依赖安全公告
2. 定期安全审计
3. 异常行为检测
4. 完整性校验
```

**响应措施**

```
1. 建立应急响应流程
2. 维护可替换组件清单
3. 快速补丁能力
4. 回滚机制
```

## 8.6.8 AI 驱动的供应链攻击：新兴威胁

随着 AI 工具深度集成到 CI/CD 流水线中，一种全新的供应链攻击模式正在浮现：**通过提示注入劫持 AI 自动化组件，进而投毒软件包或部署产物**。

2026 年 2 月的 Clinejection 事件是这一威胁的标志性案例：攻击者先通过 GitHub Issue 标题中的提示注入劫持 AI 分类机器人，再借助 GitHub Actions cache poisoning 横向影响带发布凭证的 nightly workflow。官方复盘确认曾发布异常版本 `cline@2.3.0`，但也明确说明 **未实际向用户投递恶意代码**。完整案例分析参见 [4.4.8 节](/ai_security_guide/di-er-bu-fen-gong-ji-pian/04_prompt_injection/4.4_case_studies.md)。

**AI 驱动供应链攻击的防御要点**

* **凭证隔离**：AI 自动化工作流（Issue 分类、代码审查 Bot 等）不应与发布凭证、部署密钥共享同一执行环境
* **发布门控**：任何包发布、镜像推送操作应引入独立的人工审批或多因素验证步骤
* **AI 输入消毒**：对 AI 组件处理的所有外部输入（Issue、PR 评论、Commit Message 等）实施提示注入检测
* **发布异常监控**：监控非预期的版本发布、异常的包大小变化或发布时间

供应链安全是 LLM 安全的基础。在快速迭代的 AI 领域，保持供应链的可见性和可控性至关重要。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/ai_security_guide/di-san-bu-fen-fang-yu-pian/08_architecture/8.6_supply_chain.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.