多阶段构建不能彻底防范供应链注入，但能系统性切断编译工具链在运行镜像中的残留路径，将gcc、make、curl等高风险工具严格锁死在builder阶段，确保其二进制不进入最终镜像，并需配合静态链接、显式复制、非root运行及镜像签名等配套措施。
多阶段构建本身不能“彻底剥离”或“防范供应链注入”，但它能系统性切断编译链依赖在运行时镜像中的残留路径，从而让木马无法通过构建工具链落地执行。关键不在“彻底”，而在“精准隔离”——把 gcc、make、curl、git、python 等高风险工具严格锁死在 builder 阶段，确保它们连二进制文件都不会出现在最终镜像里。
明确划分构建与运行阶段，禁止跨阶段污染
每个阶段必须使用独立命名（如 AS builder），且运行阶段基础镜像中不能预装任何编译工具。常见错误是误用 ubuntu:22.04 或 node:18 作为运行镜像——这些镜像自带 apt、curl、bash、甚至 python3，本身就是攻击面。
- 构建阶段可选
golang:1.22、node:18-alpine、rust:1.78-slim，专注下载依赖、编译、打包 - 运行阶段强制切换至
alpine:3.20、debian:slim或gcr.io/distroless/static-debian12，不带包管理器、无 shell、无调试工具 - 禁用
COPY --from=builder /app .这类宽泛复制，只写明路径：如COPY --from=builder /app/dist ./dist或COPY --from=builder /usr/local/bin/myapp .
静态编译 + 无依赖运行，从源头消除动态加载风险
对 Go、Rust、C++ 等语言，启用静态链接可避免运行时加载被篡改的 libc、openssl 等共享库。木马若想劫持动态符号解析（如 LD_PRELOAD），在纯静态二进制+distroless 镜像中完全失效。
- Go：添加
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' - Rust：在
.cargo/config.toml中设target.x86_64-unknown-linux-musl linker = "x86_64-linux-musl-gcc"，再用musl工具链构建 - 最终镜像中执行
file myapp应显示 “statically linked”，且ldd myapp返回 “not a dynamic executable”
阻断敏感文件误带入，堵住供应链投毒的隐匿通道
很多木马不靠直接执行，而是靠植入 .git/config、build.sh、Makefile 或 node_modules/.bin/webpack 等脚本，在后续 CI 构建或人工调试时被意外触发。多阶段构建必须配合显式过滤。
- 在构建阶段开头就
RUN rm -rf .git .github/ tests/ scripts/ *.sh *.yml，别等最后清理 - 用
.dockerignore排除.env、id_rsa、secrets/、package-lock.json（防恶意依赖覆盖） - 禁止在运行阶段执行
RUN apk add或apt-get install—— 所有依赖必须在 builder 阶段完成并静态打包
配套动作缺一不可，否则隔离形同虚设
仅靠多阶段构建不够。若 builder 镜像本身已被上游污染（如 node:18 预装了恶意 npm 包），或 CI 流水线允许运行任意 shell 命令，隔离就失去意义。
- 所有基础镜像启用 Docker Content Trust（DCT）：
export DOCKER_CONTENT_TRUST=1，只拉取签名镜像 - CI 中禁用
docker build --no-cache和docker build --pull的自由组合，防止绕过本地缓存拉取恶意新层 - 运行阶段必须
USER nonroot，并移除 SUID 位：RUN chmod u-s /usr/bin/* 2>/dev/null || true - 每次构建后用 Trivy 扫描 builder 和 runtime 两个镜像，对比 CVE 数量差异，验证剥离效果
