最有效做法是用 docker scout 或 trivy 扫描镜像漏洞：docker scout 官方开箱即用，支持自动与 cli 扫描；trivy 更轻量，支持离线、多语言依赖分析及 json 报告；关键在明确扫描对象、分级判定与流程集成。
直接用 Docker Scout 或 Trivy 这类工具扫描，是最有效、最贴近生产环境的做法。Docker Scout 是官方工具，开箱即用；Trivy 更轻量灵活，适合本地和 CI/CD 集成。关键不是“能不能扫”，而是“扫什么、怎么判、怎么管”。
用 Docker Scout 快速查漏洞
Docker Scout 会自动分析镜像中的操作系统包、语言依赖和配置问题，支持推送后自动扫描，也支持本地 CLI 即时检查。
- 先登录并启用插件：
docker login，然后运行docker scout enable - 对本地镜像执行扫描：
docker scout cves myapp:latest - 只关注高危以上漏洞时加参数：
--severity critical,high，配合 CI/CD 可设为失败退出 - 推送到 Docker Hub 后，进入对应仓库的 “Scout” 标签页，就能看到带修复建议的可视化报告
用 Trivy 做更细粒度的控制
Trivy 不依赖远程仓库，所有分析在本地完成，适合离线环境或私有 Registry 场景，还能识别语言级依赖（如 npm、pip、go.mod）。
- 安装后直接扫描：
trivy image --severity HIGH,CRITICAL nginx:1.25-alpine - 输出含 CVE 编号、CVSS 分数、受影响版本和官方链接，方便溯源
- 支持生成 JSON 报告：
trivy image --format json -o report.json myapp:latest，便于自动化解析 - 可配合
--ignore-unfixed过滤尚未发布补丁的漏洞，聚焦可修复项
看懂报告里的关键信息
漏洞本身只是线索，真正要判断的是：它是否在运行时被加载？是否暴露在网络边界？有没有缓解措施？
- Critical/High 级别漏洞必须处理，尤其是 OpenSSL、Log4j、glibc 等广泛使用的组件
- 注意“受影响组件”字段——如果漏洞存在于未启用的模块（如废弃的 CGI 脚本），实际风险可能较低
- 修复建议里写的版本号，要核对基础镜像源是否提供该版本（比如 Alpine 官方仓库有时滞后）
- 同一 CVE 在不同镜像中可能状态不同：有的已打补丁，有的仅靠配置规避，需结合上下文判断
把扫描真正落地到流程里
不集成进构建或推送环节的扫描，等于没扫。重点不是“扫一次”，而是让漏洞无处藏身。
- 在 GitHub Actions 或 GitLab CI 中加入扫描步骤，发现 High+ 漏洞就中断流水线
- 给不同严重等级设定响应 SLA：Critical 要求 1 小时内阻断，High 24 小时内提交修复 PR
- 定期重扫历史镜像，监控基础镜像更新（比如把
debian:12升级为debian:12.7） - 搭配
DOCKER_CONTENT_TRUST=1强制拉取签名镜像，从源头过滤不可信来源
