镜像里的操作系统也要打补丁
容器里同样跑着一套操作系统与几十个组件，基础镜像的漏洞会随业务一起上线。治理方式与主机不同：不是进入容器执行包升级，而是更新基础镜像、重建镜像、再滚动发布。镜像来源要可信，生产环境用固定版本加镜像摘要部署，避免 latest 标签随时间漂移导致同一次发布出现不同内容。
基本信息
| 适用平台 | Docker、Kubernetes 及基于 OCI 镜像的运行时 |
|---|---|
| 盘点手段 | docker images --digests、镜像扫描工具 |
| 更新方式 | 修改 Dockerfile 基础镜像版本后重建并重新发布 |
| 基线 | 镜像定期重建、来源可信、引用固定摘要 |
| 风险等级 | 中 |
典型使用场景
- 漏洞应急：基础镜像组件爆出高危漏洞时评估影响面
- 例行重建：按周期重建业务镜像，吸收上游安全更新
- 交付验收：镜像来源、摘要与扫描结果随交付物一起归档
- 供应链检查：确认镜像来自可信仓库而非个人或临时地址
- 运行态核查：确认线上运行的确实是重建后的新镜像
镜像盘点与升级
镜像盘点与升级
docker images --digests | head -20 # 查看镜像与摘要
docker scout quickview nginx:latest 2>/dev/null | head
docker run --rm nginx:1.27-alpine sh -c 'cat /etc/os-release; apk info 2>/dev/null | head -5'
docker pull nginx:1.27-alpine && docker image prune -f
docker images --format '{{.Repository}}:{{.Tag}} {{.ID}} {{.CreatedSince}}' | head -10
kubectl get pods -o jsonpath='{.items[*].spec.containers[*].image}' 2>/dev/null核查项读法
| 核查项 | 含义 | 异常表现 |
|---|---|---|
| 镜像摘要 | 内容唯一标识 | 只用 latest 时无法保证版本一致 |
| 基础镜像版本 | 如 nginx:1.27-alpine | 长期未变说明未随上游更新重建 |
| 镜像内 OS 版本 | 容器里的发行版 | EOL 版本需尽快更换基础镜像 |
| 创建时间 | 镜像构建时间 | 数百天前的镜像通常缺少安全更新 |
| 来源仓库 | 镜像拉取地址 | 个人仓库或来路不明地址属于高风险 |
镜像更新要配套重建与滚动发布流程：只 pull 新镜像不重建容器等于没更新，线上仍运行旧内容。
落地要点
- 生产部署固定版本加摘要，禁止 latest 漂移
- 把基础镜像版本与扫描结果纳入交付物归档
- 基础镜像变更后要回归业务：不同发行版基础镜像的库与工具版本差异较大
- 清理未使用镜像与悬空层，避免旧镜像长期留在宿主机
- 宿主机内核无法在容器内升级，需单独维护宿主机补丁
进入运行中的容器执行包升级只是临时手段：容器重建后改动全部丢失，正确做法是更新 Dockerfile 并重建镜像。