镜像体积优化与安全加固一体两面：选轻量基础镜像（如-alpine、distroless）、多阶段构建隔离风险、同层安装清理、ci中trivy扫描卡点闭环。

镜像体积和安全加固不是两个独立目标，而是一体两面：体积越小，攻击面越窄；剔除的冗余组件越多，潜在漏洞自然越少。关键不是“先瘦身再修漏洞”，而是用一套动作同时达成两者。

选对基础镜像，从源头掐断高危依赖

很多高危漏洞（如 OpenSSL、glibc、curl 的 CVE）来自基础镜像自带的操作系统包。直接用 ubuntu:22.04 或 centos:7 就等于默认继承了数百个带历史漏洞的二进制包。

• 优先选用官方维护的轻量级变体：如 python:3.11-slim、node:20-alpine、openjdk:17-jre-slim，它们已移除 shell、包管理器、编译工具等非运行必需项
• 更进一步可选 distroless 镜像（如 gcr.io/distroless/java17），只含运行时和 CA 证书，连 sh 都没有，彻底杜绝命令注入类漏洞
• 避免使用 latest 标签——它可能在某次更新中悄悄引入新漏洞，应固定为带补丁号的版本，例如 debian:12.7-slim

多阶段构建不只是瘦身，更是“漏洞隔离”

构建阶段需要编译器、测试工具、源码、文档等，这些全是漏洞温床。多阶段的核心价值在于：把高风险构建环境和低风险运行环境物理隔离。

• 构建阶段用完整镜像（如 maven:3.9-openjdk-17），但不保留任何中间产物
• 运行阶段只 COPY --from=builder 最终可执行文件（如 JAR、二进制、静态资源），不复制 /usr/src、/root/.m2、node_modules 等含大量第三方依赖的目录
• 实测表明：Java 应用用多阶段后，镜像中 npm、gcc、vim 等调试/开发工具全部消失，Trivy 扫描出的中高危漏洞数量下降 60% 以上

构建过程中主动清理，防止“删不干净”的漏洞残留

Dockerfile 中的 RUN rm -rf /tmp/* 不等于镜像变小——被删文件仍留在上一层。必须把安装和清理放在同一条 RUN 指令里，确保它们属于同一层。

• Debian/Ubuntu 系统：用 RUN apt-get update && apt-get install -y xxx && apt-get clean && rm -rf /var/lib/apt/lists/*
• Alpine 系统：用 RUN apk add --no-cache xxx，--no-cache 自动跳过索引缓存，不需额外清理
• Node.js 项目：安装依赖后立即执行 RUN npm ci --only=production && npm prune --production，移除 devDependencies 及其子依赖中的已知漏洞组件（如旧版 lodash、axios）

扫描不是收尾动作，而是构建流水线的强制关卡

体积优化和漏洞修复必须闭环。不能靠人工看报告，要让扫描结果决定镜像能否进入下一环节。

• 在 CI 中集成 Trivy，设定策略：发现 CRITICAL 漏洞则构建失败，HIGH 漏洞需人工确认并记录原因
• 用 trivy image --ignore-unfixed --severity CRITICAL,HIGH myapp:latest 聚焦真正需处理的问题（--ignore-unfixed 过滤掉尚无补丁的漏洞，避免误阻）
• 结合 docker history 定位哪一层引入了问题组件，例如某层显示 apk add git，就说明不该在运行镜像里装 Git——立刻删掉这行