镜像扫描通过但上线后基础镜像紧急更新，如何建立"再验证"机制不阻塞发布？

【背景】 我负责一套 K8s 1.29（containerd 1.7）集群上约 40 个微服务的镜像安全加固。CI 流水线已接入 Trivy 扫描，策略是"无 CRITICAL 方可发布"。基础镜像统一用 eclipse-temurin:17-jre，registry 内部有 mirror。

【现象】 最近两次踩坑：

1. 某服务镜像扫描通过（0 CRITICAL）后第 2 天，Alpine 基础层发布了一个 CVE-2025-XXXX（curl 远程代码执行，CVSS 9.8）。我们镜像虽然不直接依赖 curl，但同基础镜像的其他服务受影响，安全团队要求全量重新构建 + 重扫，结果发布窗口被推迟 3 天。
2. 另一次是内部 mirror 同步了上游新 tag，但 CI 里 pin 的 digest 没有更新，导致"扫描的镜像"和"实际拉取的镜像"digest 不一致，审计时发现才意识到。

【已尝试的排查与结果】

• 在 Trivy 扫描脚本里加了 --ignore-unfixed，减少噪音，但解决不了"扫描时安全、运行时不安全"的时间差。
• 试过在 CI 里把 base image digest 写死到 Dockerfile，但运维反馈"基础镜像升级时要改 40 个 Dockerfile"，维护成本太高。
• 考虑过用 admission webhook（Kyverno / OPA）在部署时校验镜像 digest 与扫描报告是否一致，但没找到现成的"扫描报告 ↔ 运行时镜像"比对方案。

【期望得到的答案形态】

1. 业界有没有成熟的"镜像再验证"（re-validation）机制？比如基础镜像更新后自动触发受影响服务的重扫 + 告警，而不是等到安全事件才被动响应？
2. digest pin 和 tag pin 在安全审计视角下怎么选？有没有"pin tag + 校验 digest"的折中做法？
3. admission 层面有没有现成方案能比对"CI 扫描时的 digest"和"Pod 实际 pull 的 digest"？
4. 如果你们团队遇到过类似问题，实际落地用了什么组合拳？请尽量给出工具名 + 配置片段或文档链接。