基础镜像中存在的漏洞通常早于业务代码出现，在Alpine、Debian和Ubuntu等官方镜像被拉取之后直接构建的过程中就已经包含了数十个已知的CVE，如果openssl、glibc或者libxml2等系统库存在未修复的高危漏洞的话，那么它就会随着镜像层一起被固化到产品中去了，在部署之后再去处理它的代价非常大。
CI 阶段应该把扫描当作硬性的门禁来对待，在镜像构建好之后、推送到仓库之前用 Trivy 进行一次快速的扫描：单二进制、无状态、支持离线漏洞库，--severity CRITICAL,HIGH --exit-code 1 可以直接中断流水线。Clair 更适合长期驻留在 Harbor 或者 Quay 中，通过 API 对仓库里的镜像进行持续的复扫，可以深入到操作系统层面做深度匹配和策略化的审计。两者的职责很明确——Trivy 负责卡住构建入口，而 Clair 则守卫着仓库中的库存量。
阻断策略不能采取“零漏洞”一刀切的方式，对于Critical级别要强制拦截；High级别需要带上修复版本或者经过带期限的例外审批；Medium和Low级别只出具报告即可。基础镜像必须锁定版本号、禁止使用latest、优先选用distroless或者精简版Alpine来降低被攻击的风险。每周根据新的基础镜像重新构建一次，同时生成SBOM文件，这样新发现的CVE就不会在已经入库的镜像中静默存在了。
不能只扫一次，门禁关闭要比扫描不准确更加危险一些。例外名单要有理由、责任人以及有效期，在仓库这边每天重新扫描一遍，在构建这边根据提交来触发，这样就形成了一个“左侧拦截+存量回顾”的循环。
镜像供应链安全的关键不是“扫出来多少”，而是“拦得住、修得动、追得到”。Trivy用来阻挡高危的基础镜像被推送到线上，Clair用来使仓库中的老旧镜像一直存在安全隐患，配合固定基础镜像、SBOM以及分级访问控制等措施来消耗掉漏洞，在构建阶段而不是生产事故中解决它。