关键在于将镜像扫描设为强制阻断关卡：critical漏洞（cvss≥9.0）必须中断流水线，high漏洞建议人工评审，结合黑白名单兜底，并在构建后、部署前集成到github/gitlab/jenkins中，规避缓存、架构、标签等执行盲区。
要在 CI/CD 流程中真正实现镜像安全防护，关键不是“扫出漏洞”，而是让高危漏洞自动触发失败、阻断发布。这需要把扫描变成不可跳过、不可忽略的强制关卡，而不是可选报告。
设定明确的阻断阈值
阻断策略必须基于实际风险分级，而非一刀切：
-
Critical（CVSS ≥ 9.0）必须中断流水线：如 Log4Shell、ProxyShell 类远程代码执行漏洞，应配置
--exit-code 1 --severity CRITICAL -
High（CVSS 7.0–8.9）建议人工评审而非硬阻断：可用
--exit-code 0 --severity HIGH单独生成报告或 MR 评论，留出修复窗口 -
忽略无补丁漏洞需谨慎启用：添加
--ignore-unfixed可避免 Alpine 等基础镜像因上游未修复而误拦，但须配合定期复核机制
集成到主流平台的实操要点
不同平台接入方式不同，但核心逻辑一致：扫描必须发生在构建之后、部署之前，且失败即终止。
-
GitHub Actions：在
build-and-push后添加docker/scout-action@v1，或直接调用docker scout cves --exit-code 1 --severity CRITICAL your-image:tag -
GitLab CI/CD：推荐使用内置模板
include: - template: Security/Container-Scanning.gitlab-ci.yml，再在项目设置中开启 “Fail pipeline on container scanning vulnerabilities” 并指定严重级别 -
Jenkins Pipeline：在
post { failure { ... } }前插入 shell 步骤，运行trivy image --exit-code 1 --severity CRITICAL $IMAGE_NAME
用黑白名单做策略兜底
自动化规则无法覆盖所有业务场景，黑白名单是必要的柔性补充：
-
漏洞白名单：对已知存在但业务无影响的 CVE（如仅限本地利用、无对应攻击面），填入漏洞编号（如
CVE-2021-44228），避免误阻断 - 漏洞黑名单：对虽被标为 Medium 但实际影响重大的漏洞（如某中间件默认配置绕过认证），主动加入黑名单强制拦截
-
镜像白名单：对历史遗留或第三方闭源镜像（如
vendor/app:2.1.0），允许其带风险上线，但需同步登记原因与替代计划
规避常见执行盲区
即使策略写对，执行环境问题也会导致扫描失效：
-
禁用镜像层缓存干扰：Trivy 或 Scout 扫描前加
--no-progress --clear-cache，防止旧缓存掩盖新引入漏洞 -
多架构镜像需显式指定平台：使用
--platform linux/amd64避免因默认架构不匹配漏扫 -
标签覆盖场景要绑定唯一标识：避免用
:latest触发扫描，改用:$CI_COMMIT_SHA或:$CI_PIPELINE_ID - 权限配置需最小化：扫描工具只需拉取镜像权限，不应赋予 registry 的 push/delete 权限
