CI/CD 中的补丁策略是什么
流水线是补丁落地的最后一公里：依赖在构建时被拉入产物，基础镜像在打包时被固化，两者决定了生产环境实际运行的是哪个版本。如果只有代码变更才触发构建，基础镜像侧的安全修复永远进不来；如果扫描卡口被临时关闭，后续构建会一直沿用被降级的策略。有效做法是把『固定版本』与『定期重建』结合起来，并保证扫描结果与制品、提交、依赖清单可互相追溯。
基本信息
| 关键动作 | 拉取含修复的依赖与基础镜像、扫描卡口、分批发布 |
|---|---|
| 固定方式 | 锁文件 + 镜像 digest 双固定，保证可复现 |
| 重建节奏 | 存量镜像按月重建，即使应用代码未变 |
| 追溯链 | 制品 → 提交 → 依赖清单 → 扫描报告 |
典型使用场景
- 基础镜像发布安全修复后，触发月度重建让存量服务获得更新
- 构建阶段扫描依赖与镜像，命中高危则阻断发布
- 紧急补丁走独立快速通道，与常规功能发布解耦
- 发布后对运行实例做一次确认扫描，验证实际部署版本
- 审计时按制品追溯：某个 CVE 从哪个提交开始被修复
流水线卡点示例
流水线卡点示例
1. 构建：拉取上游最新补丁版本（锁文件 + 镜像 digest 双固定）
2. 扫描：依赖审计 + 镜像扫描，命中高危则构建失败
3. 审批：生产发布走变更审批，紧急通道单独配置授权人
4. 发布：分批滚动，观察指标达标后继续下一批
5. 复扫：发布完成后对运行实例做一次确认扫描常见失控点
| 环节 | 失控表现 | 后果 |
|---|---|---|
| 触发条件 | 只由代码变更触发构建 | 基础镜像的安全修复长期进不来 |
| 扫描卡口 | 为发布临时关闭并被遗忘 | 高危组件随版本持续上线 |
| 版本固定 | 依赖用浮动版本标签 | 同一提交在不同时间构建出不同产物 |
| 追溯 | 制品与提交未关联 | 出问题无法定位引入点 |
定期重建是获取基础镜像修复最直接的手段：即使应用代码一行未改，也应让镜像按月走一遍构建与扫描流程。
流水线上的扫描开关与审批规则本身就是控制点，改动它们应走与生产变更同级的审批，避免『为发布临时放宽』变成长期状态。