1. 课程导入：学习目标、课程结构、AI部署流水线安全合规的重要性

1.1 为什么AI部署流水线需要单独讨论安全合规

传统软件DevOps流水线关注的是代码构建、测试、部署的效率与稳定性，其安全实践主要围绕代码仓库权限、制品签名、基础设施凭证管理展开。但AI部署流水线引入了三类传统流水线中不存在或权重极低的对象：模型权重文件、训练/推理数据集、模型运行时环境。这三类对象在流转过程中会带来全新的攻击面与合规约束。

以模型权重文件为例，一个数百MB甚至数GB的PyTorch或Safetensors文件，其内容本质上是高维浮点张量。传统代码扫描工具无法对其做语义审计，攻击者可以将恶意逻辑直接嵌入权重数值中（即“模型投毒”），在推理阶段触发特定输入下的异常行为。更隐蔽的是，权重文件本身可能包含训练数据中的个人信息，若未做差分隐私或脱敏处理，模型发布即构成隐私泄露。

数据集侧的问题同样严峻。训练数据往往来自多个上游系统，可能包含用户PII、受版权保护内容或敏感业务数据。若流水线中缺少数据血缘追踪与脱敏校验，一旦模型上线，这些信息会通过记忆效应或成员推断攻击被间接泄露。而模型运行时环境（如TensorFlow Serving、ONNX Runtime、vLLM等）的依赖链比传统Web服务更长，Python包、CUDA库、基础镜像的漏洞都可能成为攻击入口。

因此，AI部署流水线的安全合规不是传统DevSecOps的简单平移，而是需要针对模型、数据、运行时三个新对象建立专门的控制点。这也是本课程的核心出发点。

本节核心认知：AI部署流水线的安全合规 = 传统软件供应链安全 + 模型完整性保护 + 数据隐私合规 + 运行时环境加固。四者缺一不可。

1.2 课程学习目标

完成本课程后，学员应能够独立完成以下任务：

识别AI部署流水线中从数据准备、模型训练、模型注册、镜像构建到在线推理的每个阶段的安全风险点，并给出对应的控制措施。
设计并实施模型工件完整性校验机制，包括模型签名、哈希锁定、 provenance（来源）记录。
理解并应用数据合规检查（如PII检测、脱敏验证、数据血缘追踪）到自动化流水线中。
配置最小权限的部署环境，包括服务账号、网络策略、模型运行时沙箱。
编写符合审计要求的流水线日志与报告，满足等保、GDPR、AI治理等合规框架的取证需求。
针对模型投毒、提示注入、依赖漏洞等典型攻击，制定应急响应与回滚策略。

1.3 课程结构总览

本课程共30章，按知识递进关系分为六个模块。下表展示了各模块的主题与核心章节分布：

模块	主题	覆盖章节	核心交付物
一	基础与威胁建模	1-5	AI流水线威胁模型、攻击面清单
二	数据与模型工件安全	6-12	数据脱敏流水线、模型签名与验证方案
三	构建与部署环境加固	13-19	镜像扫描策略、运行时沙箱配置
四	合规与审计	20-24	合规检查点映射表、审计日志规范
五	运行时防护与监控	25-28	推理异常检测、模型漂移告警
六	综合实战与复盘	29-30	端到端安全流水线设计案例

每个章节均包含核心原理讲解、可操作的方法流程、真实案例/场景分析、常见误区与复盘四个固定模块，确保理论能落地到实际工程决策中。

1.4 AI部署流水线的典型风险场景

为了建立直观认知，我们看一个真实发生的简化案例。某金融科技公司上线了一个贷款审批辅助模型，其部署流水线如下：

数据仓库 → 特征工程 → 模型训练(内部GPU集群) → 模型注册(MLflow) → 镜像构建(Docker) → Kubernetes部署 → 在线推理API

在一次常规发布中，安全团队发现以下问题：

数据泄露风险：特征工程阶段直接读取了包含客户身份证号的数据表，且未做脱敏处理。模型在训练后记住了部分身份证号片段，通过成员推断攻击可还原出训练样本中的个人信息。
模型完整性缺失：模型注册到MLflow时未计算SHA256哈希，也未进行数字签名。攻击者若在训练到注册之间劫持传输，可替换为带有后门的模型权重。
镜像漏洞：Docker镜像基于python:3.9-slim构建，但未固定基础镜像版本，且未扫描torch==2.0.1中已知的CVE-2023-1234（存在反序列化远程代码执行漏洞）。
运行时过度权限：推理服务使用cluster-admin服务账号运行，攻击者一旦通过提示注入获得代码执行权限，可直接访问整个K8s集群的Secret。

这些问题并非个例。根据2024年的一项行业调查，超过60%的企业AI流水线在模型工件完整性、数据脱敏、运行时权限三个维度存在至少一项严重缺陷。而合规审计（如等保2.0、欧盟AI法案）正在将这些“最佳实践”逐步转为“强制要求”。

1.5 安全合规在AI流水线中的核心原则

贯穿本课程的五个核心原则，也是后续所有技术方案的设计依据：

不可信工件原则：任何进入流水线的模型、数据集、镜像、依赖包，在未经验证前均视为不可信。验证包括哈希校验、签名验证、漏洞扫描、来源追溯。
最小权限与隔离：每个流水线阶段使用独立的最小权限身份，网络层面实施微隔离，模型运行时使用沙箱或专用Pod安全策略。
可审计性：所有关键操作（数据访问、模型注册、镜像推送、部署变更）必须产生不可篡改的审计日志，日志需包含操作者、时间戳、工件哈希、审批人。
数据最小化与脱敏：训练与推理数据仅保留完成任务所必需的最小字段，且对敏感字段执行不可逆脱敏或差分隐私处理。
可回滚与可复现：每次部署必须记录完整的模型版本、数据版本、代码版本、环境依赖，确保任何时刻可回滚到已知安全状态。

常见误区：很多团队认为“只要模型推理API加了鉴权就安全了”。实际上，模型投毒、数据泄露、依赖漏洞往往发生在推理API之前——训练、注册、构建阶段。安全必须前置到流水线的起点，而非仅在出口处设防。

1.6 本节小结与学习路径建议

本节建立了AI部署流水线安全合规的整体框架。你需要记住三个关键结论：

AI流水线新增了模型、数据、运行时三个安全对象，传统DevSecOps工具无法直接覆盖。
安全控制必须嵌入流水线的每个阶段，而非仅关注最终部署环节。
合规要求（如审计日志、数据脱敏、工件签名）正在从“可选项”变为“必选项”，提前建设能显著降低后期整改成本。