最高效的安全策略注入方式是直接写入dockerfile。通过多阶段构建隔离攻击面、固定镜像来源并强制非root用户、构建时清理冗余文件、trivy扫描作为构建门禁,实现从源头控制镜像安全。

多阶段构建剥离攻击面
构建工具和调试命令是常见入口点,必须与运行环境物理隔离:第一阶段用完整镜像(如 golang:1.23-alpine 或 node:20-slim)编译代码、安装依赖;
第二阶段切换极简镜像(如 alpine:3.20 或 scratch),仅 COPY 编译产物、CA 证书等必需文件;
全程避免在最终镜像中出现 apk add、apt-get 等包管理操作,杜绝运行时安装恶意包的可能。
固定镜像来源 + 非 root 用户强制落地
使用 FROM alpine:3.20@sha256:xxx 或 FROM ghcr.io/devcontainers/base:ubuntu-22.04@sha256:xxx,从源头锁定 digest;
紧随其后执行:RUN addgroup -g 1001 -r appgroup && adduser -S appuser -u 1001;
再用 USER 1001:1001 切换上下文,配合 WORKDIR /home/appuser 和 RUN chown -R 1001:1001 /home/appuser 确保路径归属清晰。
构建时清理 + 运行前加固
安全不是“跑起来再说”,而要从构建源头控制文件系统状态:所有 RUN 指令末尾追加清理动作,例如:apk add --no-cache nginx && rm -rf /var/cache/apk/*;
删除文档、手册页、临时目录:RUN rm -rf /usr/share/doc /usr/share/man /tmp/*;
对非必要路径提前设为只读(需验证兼容性):RUN chmod -R a-w /usr/lib /usr/bin,缩小攻击者可写范围。
Trivy 扫描作为构建门禁
把漏洞检测变成构建流程的硬性关卡,而非事后审计:在 CI 脚本中,构建完成后立即执行:trivy image --exit-code 1 --severity CRITICAL,HIGH myapp:dev;
发现高危漏洞即中断推送,避免带病镜像流入仓库;
配合 --ignore-unfixed 跳过无补丁 CVE,或用自定义 trivy.rego 策略控制豁免逻辑;
生成 JSON 报告供审计:trivy image --format json -o trivy-report.json myapp:dev。
不复杂但容易忽略











