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 中调用