在镜像构建阶段嵌入安全扫描（如Trivy）并强制策略执行，是最有效的生产漏洞预防方式；需优选官方精简基础镜像、启用内容信任、多阶段构建分离、加固Dockerfile配置，并按漏洞等级定义自动化处置规则。
在镜像构建阶段就做安全扫描，是最有效预防生产漏洞的方式。它把风险拦截在上线前，避免带病镜像进入部署流程。
选对基础镜像，从源头控风险
基础镜像决定整个镜像的安全基线。优先使用官方精简版，比如 alpine:3.18 或 debian:slim，它们体积小、维护活跃、漏洞更少。避免直接用 ubuntu:latest 或第三方未经验证的镜像，这类镜像常含过时组件（如旧版 OpenSSL、curl），已有公开 CVE。
- 检查基础镜像是否定期更新：查看 Docker Hub 页面的“Last updated”时间
- 确认是否启用内容信任（Docker Content Trust）：构建前运行
export DOCKER_CONTENT_TRUST=1 - 多阶段构建中，构建阶段可用完整镜像（如
golang:1.21），运行阶段必须切换为最小化镜像
把扫描嵌入构建命令和CI/CD流程
不依赖人工触发，让每次 docker build 都自动完成安全评估。推荐用 Trivy，轻量且支持退出码控制：
- 本地构建后立即扫描：
docker build -t myapp . && trivy image --severity CRITICAL --exit-code 1 myapp - CI/CD 中设置失败阈值：发现 Critical 漏洞时让流水线中断，阻止镜像推送
- 配合 SBOM 生成：
trivy image --format sarif --output report.sarif myapp，供后续审计或平台对接
构建时加固关键配置项
Dockerfile 写法直接影响运行时风险。以下几条必须落实：
- 禁用 root 用户：
RUN adduser -D appuser && USER appuser - 挂载路径设为只读：
VOLUME ["/data"]后加ro参数，或启动时用--read-only - 删除构建缓存和临时工具：
RUN apk del .build-deps && rm -rf /var/cache/apk/*（Alpine） - 暴露端口仅限必要：
EXPOSE 80，而非开放 22、3306 等管理端口
用策略驱动扫描结果处置
扫描不是看报告就结束，要定义明确的响应规则：
- Critical 和 High 漏洞：必须修复后才能合并代码或发布镜像
- Medium 漏洞：设定修复时限（如 7 天内），超期自动告警
- 误报过滤：通过 Trivy 的
--ignore-unfixed或自定义.trivyignore文件排除已知无害项 - 基线比对：每周对同一镜像标签执行扫描，跟踪漏洞数量变化趋势
不复杂但容易忽略：真正起作用的不是工具本身，而是把扫描变成构建命令的一部分，并用策略强制执行结果处置。
