【中阶·安全】AI 供应链 SBOM 与依赖扫描实战：从模型签名到依赖链透明化的全链路安全治理专栏：《AI 工程与安全深度实战》· 第5轮·第2篇目录前言一、技术背景与演进逻辑1.1 从 SolarWinds 到 PyTorch Nightly：供应链攻击的范式转移1.2 AI 供应链与传统软件供应链的本质差异1.3 为什么 SBOM 是供应链安全的第一块多米诺骨牌二、核心原理深度解析2.1 SBOM 的数据模型与标准体系2.2 从 SBOM 到 AI-BOM：AI 物料清单的七层架构2.3 SLSA 框架：从供应链完整性到可验证的信任链2.4 模型签名与 Provenance Attestation 的密码学基础三、核心模块/流程/机制详解3.1 依赖扫描引擎的工作原理3.2 AI 模型依赖的深度解析链路3.3 模型签名与验证的完整生命周期3.4 持续 SBOM 运营：从静态快照到实时图谱四、技术优缺点与适用场景五、实战落地5.1 使用 Syft + Grype 构建传统依赖 SBOM 与漏洞扫描流水线5.2 使用 Sigstore Cosign 实现模型签名与验证5.3 构建 AI-BOM 生成流水线5.4 CI/CD 安全门禁集成5.5 企业落地场景5.6 生产避坑经验六、全文总结免责声明本期专栏更新说明专栏推荐参考资料前言核心痛点：AI 系统正以前所未有的速度吞噬开源生态——一个中等规模的 LLM 推理服务可能依赖 500+ 个 Python 包、3-5 个基础模型权重文件、多个容器基础镜像以及数十个外部 API。当这些组件中的任意一环被植入后门或存在已知漏洞时，安全团队面临的核心问题不再是"有没有漏洞"，而是"漏洞到底影响到了哪些生产服务"。传统的 CVE 扫描只能告诉你某个库"可能"有问题，但无法回答：这个模型是用哪个版本的 PyTorch 训练的？推理镜像的基础层是否存在高危漏洞？Hugging Face 上下载的 safetensors 文件是否被篡改过？本文将从 SBOM 的基础概念出发，深入到 AI-BOM 的七层架构、SLSA 供应链完整性框架、模型签名与依赖扫描的完整工具链，为读者构建一条从"知道有漏洞"到"精确知道漏洞影响范围"的 AI 供应链安全治理通路。适配人群：具备基础容器化和 Python 生态知识的 AI 工程师、MLOps 工程师、安全工程师以及需要理解 AI 供应链安全治理的技术管理者。收获能力：读完本文你将掌握：(1) SBOM/AI-BOM 的完整数据模型与生成方法；(2) SLSA 框架在 AI 场景下的落地路径；(3) Sigstore Cosign 模型签名与验证的完整实战；(4) Syft + Grype 依赖扫描流水线的搭建；(5) CI/CD 安全门禁的集成方案。一、技术背景与演进逻辑1.1 从 SolarWinds 到 PyTorch Nightly：供应链攻击的范式转移2020 年末的 SolarWinds 攻击事件让"软件供应链安全"从一个学术概念变成了董事会级别的风险议题。攻击者通过入侵 SolarWinds 的构建系统，在 Orion 平台的更新包中植入后门，最终影响了包括美国财政部、国土安全部在内的 18000+ 个组织。这一事件揭示了一个残酷的事实：你信任的每一个上游依赖，都是攻击者潜在的跳板。进入 AI 时代，攻击面不再局限于传统的 npm 包或 Maven 仓库。2022 年 12 月，PyTorch 团队披露了一起典型的供应链攻击事件：攻击者通过注册与 PyTorch 官方包名高度相似的torchtriton包（依赖混淆攻击），诱导用户在安装 PyTorch Nightly 版本时拉取恶意包。该恶意包在导入时执行信息窃取代码，收集主机的系统信息、SSH 密钥和 Git 配置。虽然该攻击在 48 小时内被发现并下架，但它暴露了一个系统性的脆弱点：AI 开发者的依赖安装习惯几乎不存在安全审查环节。以下用流程树梳理 AI 供应链攻击的典型向量：AI 供应链攻击面全景 │ ├── 依赖混淆攻击（Dependency Confusion） │ ├── 原理：利用包管理器优先拉取公共仓库的同名包 │ ├── 案例：PyTorch torchtriton（2022.12） │ └── 影响面：pip install 用户 → 信息窃取 → SSH 密钥泄露 │ ├── 模型文件投毒（Model Poisoning） │ ├── 原理：在模型权重文件中嵌入恶意代码 │ ├── 载体：Pickle 序列化格式（__reduce__ 可执行任意代码） │ ├── 案例：Hugging Face 平台恶意 Pickle 模型（2024.04） │ └── 影响面：model.load() → RCE → 容器逃逸/跨租户访问 │ ├── 镜像供应链污染 │ ├── 原理：在 Docker 基础镜像中植入恶意层 │ ├── 传播链：基础镜像 → CUDA 运行时层 → 推理镜像 → K8S Pod │ └── 影响面：整个推理集群被持久化控制 │ ├── 数据集投毒（Dataset Poisoning） │ ├── 原理：在公开训练数据集中注入恶意样本 │ ├── 影响面：模型后门化 → 特定触发条件下产生恶意输出 │ └── 隐蔽性：极难通过常规测试发现 │ └── 外部 API 劫持 ├── 原理：替换或中间人攻击模型推理时调用的外部 API ├── 案例场景：RAG 检索增强生成中外部知识库被污染 └── 影响面：推理结果被恶意操纵，但模型本身无异常1.2 AI 供应链与传统软件供应链的本质差异传统软件供应链安全聚焦于"代码 → 构建 → 制品"这条链路，核心资产是源代码、编译后的二进制文件和容器镜像。AI 供应链在此基础上引入了三个全新的维度：维度传统软件供应链AI 供应链核心制品二进制文件、JAR、Wheel、Docker 镜像模型权重文件（.pt / .safetensors / .h5 / .onnx）、训练数据集、推理配置构建过程编译 + 链接 + 打包（确定性）训练（非确定性，随机种子、GPU 浮点运算差异）依赖类型库依赖（静态声明，如 requirements.txt、pom.xml）模型依赖 + 数据依赖 + 运行时依赖（动态解析）分发渠道制品仓库（PyPI、npm、Maven Central）模型注册中心（Hugging Face Hub、ModelScope）+ 容器镜像仓库签名与完整性GPG 签名、Checksum（哈希校验）模型签名（Sigstore）、Provenance（训练过程证明）漏洞类型CVE（已知漏洞数据库）CVE + 模型后门 + 对抗性弱点 + 数据偏见生命周期发布周期（周/月级）持续迭代（模型微调、LoRA Adapter 热更新）核心矛盾：传统供应链安全工具（SCA 扫描器）只能识别"库依赖"这个维度的风险，而 AI 供应链中的模型权重、训练数据、推理运行时都是传统工具的盲区。以 Hugging Face 上的一个典型 LLM 模型仓库为例，其文件结构如下：model-repo/ ├── config.json ← 模型架构配置（传统扫描器不会解析） ├── tokenizer.json ← 分词器配置（可能包含恶意 token 映射） ├── model.safetensors ← 模型权重（安全格式） ├── pytorch_model.bin ← 模型权重（Pickle 格式，高危！） ├── training_args.bin ← 训练参数（Pickle，同样高危） └── requirements.txt ← 这是传统扫描器唯一能识别的内容1.3 为什么 SBOM 是供应链安全的第一块多米诺骨牌SBOM（Software Bill of Materials，软件物料清单）的概念源自制造业的 BOM 理念：在食品行业你需要知道原料来源，在汽车行业你需要知道每个零部件的供应商，在软件行业你需要知道你的应用由哪些组件构成。SBOM 不是安全工具，而是安全决策的数据基础——没有准确的物料清单，所有的漏洞扫描、合规审计、应急响应都是在盲打。2026 年，SBOM 领域经历了从"合规快照"到"运营化数据"的关键转变。三个推动力加速了这一转变：监管驱动：EU Cyber Resilience Act（CRA，法规 EU 2024/2847）要求所有进入欧盟市场的含数字元素产品必须具备可查询的供应链证据体系；CISA 于 2025 年更新了 SBOM 最小元素要求；G7 网络安全工作组于 2026 年 5 月联合发布了全球首份《SBOM for AI》联合指南，要求 AI 系统的物料清单覆盖模型、数据集、软件组件和基础设施四层。攻击驱动：PyTorch torchtriton（2022）、Hugging Face Pickle 注入（2024）、Mastra npm 包攻击（2025，通过窃取贡献者凭证篡改了 144 个包）等事件的连续爆发，证明 AI 供应链已成为攻击者的高价值目标。治理驱动：NIST AI Risk Management Framework 和 EU AI Act 的逐步落地，要求组织能够为每个 AI 系统提供可追溯的组件清单和风险评估记录。下面用 TEXT 图描述从"静态 SBOM"到"运营化 SBOM"的演进路径：┌─────────────────────────────────────────────────────────────────┐ │ SBOM 成熟度演进模型 │ │ │ │ Level 0: 无 SBOM Level 1: 静态 SBOM Level 2: 运营化 │ │ ─────────────── ──────────────── ────────────── │ │ · 不知道用了什么 · 构建时生成 · 持续更新 │ │ · 依赖口头传播 · 以文档形式归档 · 与 CVE Feed │ │ · 无任何审计能力 · 事后审计可用 实时关联 │ │ · 但信息快速过时 · 结合 VEX │ │ · 可查询 API │ │ │ │ Level 3: 策略驱动 Level 4: 智能治理 │ │ ──────────────── ──────────────── │ │ · SBOM 与 Policy Engine · AI Agent 自动 │ │ 集成 发现→分析→修复 │ │ · 自动阻止不达标组件 · 从 MTTR 周级 │ │ · 许可证合规自动检查 压缩到分钟级 │ │ │ └─────────────────────────────────────────────────────────────────┘二、核心原理深度解析2.1 SBOM 的数据模型与标准体系SBOM 的标准化经历了多年的竞争和融合。当前主流标准有三个，它们的关系如下表：标准发起方数据格式核心特点行业采纳SPDX(3.0+)Linux FoundationJSON-LD / YAML / RDF / Tag-Value侧重于许可证合规，支持 AI 和 Dataset ProfileISO/IEC 5962:2021，开源社区首选CycloneDX(1.6+)OWASPJSON / XML侧重于安全风险，原生支持漏洞关联（VEX）、依赖图安全工具生态广泛支持SWIDISO/IECXML侧重于软件资产管理，标记软件身份企业 IT 资产管理场景对于 AI 场景，SPDX 3.0 增加了 AI Profile 和 Dataset Profile，能够描述模型训练数据、模型架构、超参数和评估指标；CycloneDX 1.5+ 引入了 ML-BOM（Machine Learning Bill of Materials）扩展，支持模型卡（Model Card）、数据来源等元数据。两个标准的竞争关系决定了当前没有任何单一标准可以覆盖所有 AI 供应链需求，实际落地中需要"双标准并行"策略。一个典型的 SBOM 最小元素包括以下字段：最小 SBOM 元素（CISA 2025 定义） ├── 基础标识 │ ├── Supplier：组件供应商/作者 │ ├── Component Name：组件名称 │ ├── Version：版本字符串 │ ├── Unique Identifier：唯一标识（PURL / CPE / SWID Tag ID） │ └── Dependency Relationship：依赖关系（上游/下游） ├── 时间与来源 │ ├── Author：SBOM 作者 │ └── Timestamp：生成时间戳 └── 扩展元素（按需） ├── License：许可证信息 ├── Hash：文件级哈希值（SHA-256） ├── CPE / PURL：标准化的包标识符 └── VEX 关联：漏洞可利用性交换信息2.2 从 SBOM 到 AI-BOM：AI 物料清单的七层架构当我们将 SBOM 的概念扩展到 AI 系统时，传统的"依赖列表"模式瞬间失效——一个 LLM 推理服务的完整物料清单需要覆盖从底层 GPU 驱动到顶层模型行为边界的全部组件。基于 Wiz 提出的 AI-BOM 模型以及 G7《SBOM for AI》指南，我们将 AI-BOM 定义为七层架构：AI-BOM 七层架构 │ ├── Layer 1: 数据层（Data Layer） │ ├── 训练数据：来源（公开数据集/内部数据）、许可证、预处理流水线 │ ├── 推理数据：Feature Store、向量数据库、实时 API 数据源 │ └── 数据存储：S3/MinIO 桶、数据湖、数据仓库 │ ├── Layer 2: 模型层（Model Layer） │ ├── 基础模型：GPT-4o-mini / Llama-4 / Qwen3 / DeepSeek-V3 等 │ ├── 微调模型：LoRA Adapter / QLoRA 权重 / 全参微调 Checkpoint │ ├── 内部训练模型：自研架构、自定义算法 │ └── 版本与配置：模型版本号、超参数（学习率、Batch Size）、量化方式（FP16/BF16/INT8/INT4） │ ├── Layer 3: 依赖层（Dependency Layer） │ ├── ML 框架：PyTorch 2.6 / TensorFlow 2.18 / JAX 0.5.x │ ├── AI SDK：OpenAI SDK / Anthropic SDK / LangChain / LlamaIndex │ ├── 第三方包：transformers、vLLM、TGI、FastAPI、Pydantic │ └── 运行时依赖：CUDA Toolkit、cuDNN、NCCL、TensorRT │ ├── Layer 4: 基础设施层（Infrastructure Layer） │ ├── 计算资源：NVIDIA A100/H100/B200 GPU、TPU v5p、NPU 昇腾 910B │ ├── 容器编排：Kubernetes 1.32、NVIDIA GPU Operator、Volcano Scheduler │ ├── 存储网络：RDMA InfiniBand、NVLink、CSI 存储驱动 │ └── 云平台配置：AWS/Pod 身份、GCP Workload Identity、IAM 角色绑定 │ ├── Layer 5: 安全与治理层（Security Governance Layer） │ ├── 身份与访问：Service Account、IAM Role、API Key、OAuth Token │ ├── 网络访问路径：模型 → 外部 API → 向量数据库 → 数据源 │ └── 安全策略：Pod Security Standards、NetworkPolicy、OPA/Gatekeeper 规则 │ ├── Layer 6: 人员与流程层（People Process Layer） │ ├── 所有权：模型 Owner、数据 Owner、服务 Owner │ ├── 变更历史：谁、何时、为什么修改了模型/数据/配置 │ └── 审批工作流：模型变更 → Review → 测试 → 审批 → 部署 │ └── Layer 7: 文档与治理层（Documentation Governance Layer） ├── 模型卡片（Model Card）：用途、限制、性能基准、偏见评估 ├── 数据卡片（Data Sheet）：数据来源、收集方法、标注质量 └── 使用策略：可接受使用范围、禁止使用场景、合规声明这七层架构的核心设计思想是：AI-BOM 不仅仅是"依赖列表"，而是对 AI 系统运行时的完整拓扑关系建模。安全事件发生后，你需要的不是"系统中用了哪个模型"，而是"哪个服务通过哪条路径访问了受影响的模型版本，该模型又是用哪个版本的数据集训练的，训练时使用了哪个可能存在漏洞的 PyTorch 版本"——这是一个跨越多层的依赖溯源问题。2.3 SLSA 框架：从供应链完整性到可验