docker scan 只能检测镜像最终文件系统中的软件包漏洞，无法分析 Dockerfile 构建逻辑或中间层问题；它依赖 Snyk 云服务，仅支持已构建镜像，不解析语法、不查敏感文件、不验证构建步骤。
docker scan 不是 Docker 内置指令，而是 Docker CLI 的一个插件（docker-scan），底层调用的是 Snyk。它**只分析最终镜像的软件包层，无法回溯或解析 Dockerfile 构建步骤本身**。想靠 docker scan nginx:latest 发现 “为什么 COPY 了 .env 文件” 或 “USER 指令被跳过” 这类构建逻辑缺陷，注定失败。
docker scan 能查什么、不能查什么
它能做的：读取镜像文件系统，提取已安装的二进制/库（如 openssl、curl、python3），比对 NVD/CVE 数据库，报告这些组件的已知漏洞（CVE-2021-44228）、许可证风险或过期版本。
它不能做的：
– 不解析 Dockerfile 语法或执行顺序
– 不检测 RUN apt-get install -y wget && rm -rf /var/lib/apt/lists/* 中的中间层残留
– 不发现 COPY . . 带入的 id_rsa 或 .git 目录
– 不验证 USER 是否真正在运行时生效（只看最终文件属主）
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 误以为
docker scan能替代hadolint或checkov是最常见误区 - 它不检查构建缓存污染、多阶段构建中未清理的构建工具（如
gcc、make） - 扫描结果里出现 “
high severity” 漏洞，往往源头在基础镜像或RUN命令里没做--no-install-recommends
真正能分析构建过程缺陷的替代方案
要定位构建阶段引入的问题，必须换工具链：
-
hadolint：静态检查Dockerfile语法与安全实践，比如报错DL3007: Using latest is prone to errors if the image is updated或DL3002: Last user should not be root -
trivy config：扫描Dockerfile和docker-compose.yml，识别硬编码密钥、特权模式、不安全挂载等配置问题 -
syft+grype：先用syft生成 SBOM（软件物料清单），再用grype扫描——可精确到每个 layer 的包来源，辅助判断是哪一层引入了libpng等依赖 - 手动 inspect：用
docker history --no-trunc <image>查看各层命令，结合docker save <image> | tar -t | grep -E '\.(pem|key|env)$'快速排查敏感文件残留
docker scan 的实际使用边界
如果你仍要用 docker scan，必须清楚它的输入和约束：
- 它只接受已存在的镜像名或本地 tar 包，不接受 Dockerfile 路径
- 需提前登录（
docker login），否则私有仓库镜像拉取失败，报错unauthorized: authentication required - 默认只输出 high/critical 级别漏洞；加
--severity critical,high,medium才能看到全部 - 离线不可用——它依赖 Snyk 云服务更新的漏洞库，断网即失败，错误信息是
failed to fetch vulnerability database - 扫描结果中的 “fix version” 建议常不可行，比如提示升级
openssl到 3.0.13，但你的基础镜像可能根本没提供该版本
构建过程的安全缺陷，本质是开发流程问题，不是镜像内容问题。指望一个只读取最终文件系统的工具去诊断构建逻辑，就像用体温计查阑尾炎的位置——量得准，但找不准病灶在哪一层。
