关键在于将扫描嵌入构建、仓库和部署全流程以阻断风险：构建阶段用Trivy/Docker Scout自动扫描并失败终止；仓库层通过Harbor策略、签名验证和白名单拦截缺陷镜像；部署前用OPA/Gatekeeper校验K8s准入策略；最后推动修复闭环，包括版本提示、自动告警和SBOM管理。
关键在于把扫描嵌入构建和部署流程，在镜像真正运行之前就卡住风险。不是等容器跑起来再查，而是让不合规的镜像根本进不了仓库或集群。
构建阶段：用Trivy或Docker Scout自动扫描镜像
在CI流水线中构建完镜像后，立即调用扫描工具。比如用Trivy检查高危和严重漏洞：
-
本地验证：执行
trivy image --severity HIGH,CRITICAL myapp:latest，返回非零退出码即表示存在阻断项 - CI集成：在GitHub Actions或GitLab CI中加入扫描步骤，失败则终止流水线
-
Docker Scout快捷方案：推送镜像到Docker Hub后自动触发扫描，配合
--exit-code参数可强制失败（如发现CRITICAL漏洞时）
镜像仓库：设置准入策略拦截带缺陷镜像
光靠构建时扫描不够，还需在仓库层加一道闸门，防止绕过CI的镜像入库：
- 配置镜像仓库（如Harbor）的漏洞扫描策略，对CRITICAL漏洞直接拒绝推送
- 启用镜像签名验证（cosign），只允许已签名且通过扫描的镜像被拉取
- 建立基础镜像白名单，禁止使用
latest或未经审计的第三方镜像
部署前：用OPA/Gatekeeper做K8s准入校验
即使镜像进了仓库，也不能默认信任。在Kubernetes部署前做最后一道策略检查：
- 部署OPA或Gatekeeper，编写策略规则，例如“禁止运行特权容器”“必须设置readOnlyRootFilesystem”
- 结合Trivy扫描报告生成的标签（如
vulnerability-score=2），在策略中限制高分镜像不得部署 - 将镜像CVE数量、最高风险等级作为 admission webhook 的判断依据
修复闭环：不只是拦截，还要推动修复落地
拦截只是手段，目标是让问题真正被解决：
- 扫描报告里明确标出可修复版本（如“升级openssl至1.1.1w可修复CVE-2023-0286”）
- 把漏洞详情自动写入issue或飞书/钉钉告警，关联到对应服务负责人
- 对反复出现同类漏洞的团队，推动基础镜像统一升级或引入SBOM清单管理
