ADD指令无下载校验与安全检查能力，需开发者主动设计校验流程；应避免直接下载公网未认证URL，优先使用curl/wget配合SHA256/PGP签名验证，并禁用自动解压、控制权限与路径遍历风险。
ADD 指令本身不提供下载校验或安全检查能力，它只是复制文件或从 URL 获取内容并解压（若为归档）的简单操作。真正的校验与安全需由开发者主动设计流程来保障。
下载前必须校验来源可信性
从远程 URL 使用 ADD（如 ADD https://example.com/app.tar.gz /app/）时，Docker 构建过程不会验证 TLS 证书、域名真实性或服务端身份。攻击者若劫持 DNS 或中间人攻击，可能返回恶意内容。
- 优先使用镜像内已安装的工具（如 curl + wget）配合显式校验步骤，而非依赖 ADD 的隐式下载
- 避免直接 ADD 公网未认证 URL；改用构建参数（
BUILD_ARG）传入经 CI/CD 流水线预检过的内网制品地址 - 若必须用 ADD 下载，确保基础镜像系统时间准确、CA 证书更新，并搭配可信 DNS（如 1.1.1.1）
文件完整性需独立校验（SHA256/PGP）
ADD 不校验哈希或签名。即使下载了正确 URL 的文件，也可能因网络损坏、镜像仓库被篡改或上游发布失误导致内容异常。
- 在 ADD 后立即执行校验命令，例如：
RUN curl -fsSLO https://example.com/app.tar.gz && \<br> curl -fsSLO https://example.com/app.tar.gz.sha256 && \<br> sha256sum -c app.tar.gz.sha256 && \<br> tar -xzf app.tar.gz -C /app - 将校验值硬编码进 Dockerfile（不推荐）或通过
--build-arg注入，提升可审计性 - 对关键组件（如二进制、脚本），优先获取 PGP 签名并用 gpg 验证发布者身份
权限与解压行为需显式控制
ADD 对 tar 包会自动解压，且默认以 root 权限提取到目标路径，可能覆盖已有文件、执行隐藏脚本（如 GNU tar 的 --owner 或 --group 滥用）、甚至触发 CVE-2021-20305 类漏洞。
- 禁用自动解压：改用
COPY+ 显式tar -x --no-same-owner，避免继承原始 tar 中的 UID/GID - 限制解压目标路径权限，例如先
RUN mkdir -p /app && chown nobody:nogroup /app，再以非 root 用户解压 - 对未知来源 tar 包，在解压前用
tar -t检查路径是否含../（路径遍历风险）
替代方案更利于安全实践
现代最佳实践倾向于规避 ADD 的隐式行为，转而用更可控、可审计的方式管理依赖。
- 使用多阶段构建：在 builder 阶段下载+校验+编译，仅 COPY 编译产物到运行镜像，减少攻击面
- 利用 BuildKit 的
RUN --mount=type=cache或--mount=type=secret安全传入 token 或私钥，避免硬编码凭据 - 将校验逻辑封装为 shell 脚本或 Makefile，统一管理哈希清单和签名验证流程，再在 Dockerfile 中调用
