镜像漏洞扫描不是把工具接到CI里跑一次就结束。真正的问题是：什么时候扫描、扫描结果谁负责、哪些漏洞必须阻断、哪些可以例外、修复后如何验证、已运行的镜像是否需要复扫。没有治理闭环的扫描，很容易变成告警堆积；没有扫描依据的治理，又容易变成主观拦截。
对于Kubernetes环境，镜像是应用交付的核心载体。镜像中的操作系统包、语言依赖、运行时组件和配置文件，都会影响集群安全边界。容器安全治理应把镜像扫描放在构建、入库、部署和运行全链路中。
镜像漏洞扫描应该放在哪些环节
第一类是构建阶段扫描。它能尽早发现基础镜像和应用依赖问题，适合给开发团队快速反馈。第二类是镜像入库扫描。镜像推送到仓库后，仓库可以根据项目、严重度和策略决定是否允许分发。第三类是部署前准入。Kubernetes准入控制可以检查镜像扫描状态、签名、来源和策略标签，阻止不符合要求的镜像上线。第四类是运行中复扫。漏洞数据库会持续更新，昨天合规的镜像今天可能出现新漏洞。
这些环节的策略强度不应完全相同。构建阶段适合快速反馈，入库阶段适合统一基线，部署阶段适合执行红线，运行阶段适合识别存量风险。把所有压力放在某一个阶段，往往会造成告警延迟或发布拥堵。
扫描结果不能只看严重度
很多团队把漏洞治理简单等同于“高危必须修”，实际落地时会遇到大量例外：漏洞包存在但代码路径不可达、镜像不对外暴露、基础镜像暂未提供修复版本、升级会影响业务兼容。完全忽略这些因素会造成无效工作；完全放开又会削弱安全门禁。
更合理的风险分级应同时看漏洞严重度、是否已有公开利用方式、受影响组件是否在运行时实际存在和可达、镜像部署的业务重要性、网络暴露面、权限级别、是否存在可用修复版本、是否涉及合规要求或内部安全红线。这样才能把有限修复资源投向真正高风险镜像，而不是让团队在大量低价值告警中消耗。
如何形成修复闭环
一次完整闭环至少包括发现、归属、修复、验证和沉淀。扫描平台发现问题后，应能映射到镜像仓库项目、应用、负责人和部署环境。没有责任归属的漏洞，很难进入迭代计划。
修复方式通常有三类。第一，升级基础镜像或系统包。第二，升级应用依赖或重新构建镜像。第三，在无法立即升级时采取临时缓解，例如关闭受影响功能、限制网络暴露或增加运行时策略。临时缓解必须有到期时间，不能永久替代修复。
验证阶段应重新扫描同一镜像版本或新版本，并确认部署环境已经使用修复后的镜像。仅仅在代码仓库合并修复，不代表生产集群已经消除风险。
与Kubernetes准入控制如何配合
准入控制适合处理明确、可自动判断的红线，例如禁止未扫描镜像、禁止来自未知仓库的镜像、禁止未签名生产镜像、禁止超过策略阈值且无例外单的镜像。对于需要人工判断的漏洞，准入系统应支持例外流程和审计记录。
策略设计建议分阶段推进：先观测，只记录不阻断，评估影响范围；对新建应用或低风险环境启用软阻断；对生产环境核心规则启用强制阻断；建立例外审批、过期提醒和复核机制。如果一开始就把所有高危漏洞都作为强阻断条件，可能造成发布拥堵，业务团队也会绕过平台流程。治理的关键是可解释、可执行、可持续。
治理指标看什么
镜像漏洞治理需要指标，但指标不应只看漏洞数量。更有价值的指标包括：未扫描镜像占比、高风险镜像修复时长、生产环境例外数量、基础镜像版本分布、重复漏洞来源、阻断策略命中率、修复后复发率。
这些指标可以帮助平台团队判断：是基础镜像基线过旧，还是业务依赖升级滞后；是扫描工具误报过多，还是责任归属不清；是准入策略太松，还是发布流程缺少缓冲。对于容器镜像基础治理，可结合容器技术专题中的Dockerfile安全和镜像仓库策略一起推进，避免扫描结果只停留在报告层面。
常见问题
镜像扫描发现高危漏洞就一定不能上线吗？
不一定，但必须有明确判断依据。若漏洞存在公开利用方式、组件在运行路径中可达、镜像部署在生产暴露面上，通常应阻断或先修复。若漏洞不可达、无修复版本且已有缓解措施，可以通过例外流程临时放行。关键是例外要有负责人、到期时间和复核记录，不能把“业务紧急”变成长期豁免。
为什么同一个镜像不同工具扫描结果不一样？
扫描工具使用的漏洞数据库、包识别方式、语言依赖解析能力和严重度映射规则不同，结果可能存在差异。治理时应统一企业认可的扫描口径，并允许安全团队对争议漏洞做裁决。对于关键镜像，可以使用多工具交叉验证，但最终仍要落到统一策略和修复闭环上。
只扫描CI新构建镜像够不够？
不够。漏洞数据库不断更新，存量镜像和正在运行的Pod也可能在之后暴露风险。CI扫描适合早发现，仓库扫描适合统一管理，准入扫描适合上线把关，运行中复扫适合识别存量风险。企业容器安全治理应把这些环节组合起来，而不是只依赖某一个扫描点。
转载请注明出处：https://www.cloudnative-tech.com/p/7467/
