docker push前必须扫描镜像，否则漏洞、密钥等风险将裸奔上线；应在build后、push前用trivy --exit-code 1同步扫描并校验退出码，而非依赖registry异步拦截。

为什么 docker push 之前不扫描镜像，等于裸奔上线

镜像里藏着漏洞、硬编码密钥、违规基础镜像——这些不会在 docker push 时自动报错，但一推到 registry 就可能被攻击面暴露。CI 流水线里跳过扫描，等于把安全左移变成了“左忘”。

• 常见错误现象：docker push 成功，但第二天收到 SCA 工具告警：镜像含 CVE-2023-1234 高危漏洞，且已部署到预发环境
• 根本原因：Docker 本身不校验内容安全性，push 只做传输和存储，不触发任何审计逻辑
• 真正该拦截的位置：在 docker build 完成后、docker push 前，用独立工具对 image id 或 repo:tag 扫描并强制校验退出码

trivy image 扫描失败的三个典型卡点

trivy 是目前最轻量又可靠的 CLI 扫描器，但直接套命令常踩坑。

• trivy image --severity CRITICAL myapp:latest 不会阻断推送：默认只输出结果，返回码恒为 0，必须加 --exit-code 1 --skip-update
• 离线环境扫不了：trivy 默认联网拉漏洞库，CI 节点没外网时会超时卡住，得提前用 trivy image --download-db-only 同步 trivy.db 到共享路径
• 多阶段构建镜像扫空：如果只构建了 builder 阶段（如 docker build --target builder），而没指定最终运行镜像，trivy 扫的是空层或中间镜像，得确认扫描对象是 final 阶段生成的 image id

如何让 docker push 自动失败在漏洞超标时

核心是把扫描变成 shell 命令链中的一环，靠退出码驱动流程走向。

• 推荐写法（Bash）：

  trivy image --exit-code 1 --severity CRITICAL,HIGH --skip-update myapp:latest && docker push myapp:latest

• 注意 --exit-code 1 必须显式指定，否则即使发现 CRITICAL 漏洞也返回 0
• CI 中建议加 --timeout 5m 防止扫描卡死阻塞流水线
• 若用 GitHub Actions，别把 trivy 放在 docker/build-push-action 的同一 step，它俩不共享文件系统；应先 docker build -t myapp:latest .，再单独 step 扫描

registry 级别的推送拦截为什么不可靠

有人想在 Harbor 或 ECR 启用“阻止高危镜像推送”，这思路看似省事，实则危险。

• Harbor 的 vulnerability scan 是异步的：镜像已入库，扫描才开始，等结果出来早推完了
• ECR 的 image scanning 默认关闭，开启后也是事后触发，且不支持自定义阻断策略（比如只拦 CRITICAL，放过 HIGH）
• 真正可控的拦截点只有一个：本地或 CI 构建机上，对即将推送的镜像做同步扫描 + 退出码判断
• 额外成本低：一次 trivy 扫描平均耗时 10–40 秒，远低于构建本身，但能挡住 90% 的已知漏洞镜像上线

最易被忽略的是镜像标签污染：同一个 myapp:latest 可能被不同分支反复构建推送，但扫描脚本若没绑定具体 image id，就可能扫了旧缓存层，漏掉新引入的漏洞。