TL;DR镜像扫描解决已知漏洞是安全基线镜像签名确保内容可信防篡改保障SBOM提供供应链透明度便于审计追溯Kyverno在准入阶段强制校验签名与漏洞策略建议从 CI 扫描起步逐步完善签名与供应链治理。摘要容器镜像安全是云原生交付的底线。本文系统讲解镜像扫描如何发现已知漏洞、镜像签名如何确保内容可信、SBOM如何提供供应链透明度并结合 Kyverno 在 Kubernetes 准入阶段强制落地安全策略帮助你在构建、存储、分发、运行全链路建立可信防线实现端到端的供应链安全治理。1. 引言2024 年某知名开源镜像仓库被曝出投毒事件攻击者将恶意代码植入多个热门镜像的构建脚本中在镜像被拉取后静默执行挖矿程序并窃取环境变量中的密钥。由于这些镜像被大量企业直接引用事件波及范围迅速扩大多家公司被迫紧急排查并重建镜像。这并非孤例——从基础镜像的已知漏洞到构建期植入的恶意代码再到运行时被篡改的内容每一次拉取与部署都可能成为攻击入口。镜像安全刻不容缓。本文聚焦三道关键防线镜像扫描发现已知漏洞、镜像签名确保内容可信、SBOM 与供应链安全从源头建立信任并给出从 CI 扫描到 Kubernetes 准入校验的完整落地路径。## 2. 为什么镜像安全如此重要镜像一旦被发布到仓库并被拉取运行其内容就等同于线上运行的代码。如果镜像中存在高危漏洞或恶意组件攻击者无需直接攻破你的服务器只需利用镜像内的缺陷即可完成入侵。更严重的是镜像具有复用性与传播性——一个被污染的公共基础镜像可能被成千上万个下游项目引用形成供应链级别的连锁污染。因此镜像安全不仅是「上线前的一次检查」而应贯穿镜像的构建、存储、分发、运行全生命周期。3. 镜像扫描发现已知漏洞3.1 扫描的原理镜像扫描的核心思路是将镜像内的软件包清单如操作系统包、语言依赖、二进制文件与漏洞数据库如 CVE、NVD、OSV进行比对找出已知漏洞并评估其风险等级。扫描通常分为两类静态扫描在镜像构建后、运行前对镜像层文件系统进行分析识别其中的软件版本并匹配漏洞库。运行时扫描对正在运行的容器进行实时检测发现动态引入的风险如运行时下载的恶意依赖。3.2 常用扫描工具工具特点适用场景Trivy轻量、速度快、覆盖 OS 包与语言依赖CI 阶段快速扫描Clair由 CoreOS 开源支持 API 集成仓库侧集中扫描Anchore策略引擎强大支持自定义规则企业级合规管控GrypeAnchore 出品与 Syft 配合与 SBOM 联动3.3 扫描的落地实践# 使用 Trivy 扫描本地镜像trivy image--severityHIGH,CRITICAL --ignore-unfixed myapp:latest# 在 CI 中阻断高危漏洞trivy image --exit-code1--severityCRITICAL myapp:latest建议将扫描嵌入 CI 流水线高危漏洞直接阻断发布中低危漏洞记录并跟踪修复。同时扫描结果应生成报告归档便于审计与追溯。4. 镜像签名确保内容可信4.1 为什么需要签名扫描只能发现「已知漏洞」却无法防止「内容被篡改」。攻击者可能通过劫持镜像仓库、中间人攻击或内部人员操作替换或篡改镜像内容。镜像签名通过密码学手段为镜像内容生成不可伪造的数字签名确保拉取到的镜像确实来自可信发布者且未被篡改。4.2 签名的工作原理签名流程通常包含以下步骤发布者使用私钥对镜像的 manifest清单进行签名签名结果与公钥信息一同发布到仓库或独立的签名存储拉取方使用公钥验证签名确认镜像来源与完整性。是否开发者构建镜像使用私钥签名推送镜像与签名到仓库用户拉取镜像使用公钥验证签名验证通过?允许运行拒绝运行并告警4.3 主流签名方案CosignSigstore 项目的一部分支持无密钥签名Keyless与 OCI 仓库天然集成是目前最流行的方案。NotationCNCF 孵化项目基于 OCI 1.1 规范适合与云厂商生态结合。Docker Content TrustDCTDocker 原生方案基于 Notary适合 Docker 生态内的简单场景。4.4 Cosign 实践示例# 生成密钥对cosign generate-key-pair# 对镜像签名cosign sign--keycosign.key myregistry/myapp:latest# 验证镜像签名cosign verify--keycosign.pub myregistry/myapp:latest在 Kubernetes 中可结合Kyverno或Ratify等策略引擎在准入控制阶段强制校验镜像签名未通过验证的镜像直接拒绝创建 Pod。5. 软件供应链安全从源头建立信任5.1 供应链风险的来源镜像的供应链风险不仅来自镜像本身还来自其依赖的上游组件基础镜像如alpine、ubuntu本身存在漏洞第三方依赖库被投毒如恶意 npm 包、PyPI 包构建工具链被篡改构建过程使用了不可信的缓存或代理。5.2 SBOM软件物料清单SBOMSoftware Bill of Materials是镜像内所有组件的清单相当于「镜像的配料表」。通过 SBOM你可以快速定位漏洞影响的组件范围满足合规审计要求如美国 EO 14028、欧盟 Cyber Resilience Act在漏洞爆发时第一时间评估自身受影响程度。# 使用 Syft 生成 SBOMsyft myapp:latest-ospdx-jsonsbom.json# 使用 Grype 基于 SBOM 扫描漏洞grype sbom:./sbom.json5.3 供应链安全的整体实践5.4 供应链安全实战从 SBOM 到策略落地下面用一个完整的端到端示例把 SBOM 生成、漏洞扫描、镜像签名与 Kubernetes 准入校验串联起来展示一条可落地的供应链安全闭环。第一步生成 SBOM 并扫描漏洞# 生成 SBOMSPDX 格式syft myapp:latest-ospdx-jsonsbom.json# 基于 SBOM 扫描漏洞输出 JSON 报告grype sbom:./sbom.json-ojsonvuln-report.json# 查看高危漏洞摘要grype sbom:./sbom.json --only-severity critical,high第二步对镜像签名并推送# 生成密钥对生产环境建议使用 KMS 或 Sigstore Keylesscosign generate-key-pair# 对镜像签名cosign sign--keycosign.key myregistry/myapp:latest# 推送镜像与签名到仓库dockerpush myregistry/myapp:latest cosign push--keycosign.key myregistry/myapp:latest第三步用 Kyverno 在准入控制阶段校验签名与漏洞策略创建 Kyverno 策略强制要求镜像必须通过签名验证并拒绝携带高危漏洞的镜像apiVersion:kyverno.io/v1kind:ClusterPolicymetadata:name:require-image-signaturespec:validationFailureAction:Enforcerules:-name:verify-cosign-signaturematch:any:-resources:kinds:-PodverifyImages:-imageReferences:-myregistry/myapp:*attestors:-count:1entries:-keys:publicKeys:|------BEGIN PUBLIC KEY-----cosign.pub 内容-----END PUBLIC KEY-----再创建一条策略基于镜像漏洞扫描结果阻断高危镜像部署需配合Ratify或Kyverno 的 imageVerify扩展apiVersion:kyverno.io/v1kind:ClusterPolicymetadata:name:block-high-vulnerability-imagesspec:validationFailureAction:Enforcerules:-name:reject-critical-vulnsmatch:any:-resources:kinds:-Podvalidate:message:镜像存在高危漏洞禁止部署deny:conditions:any:-key:{{ image.ratify.vulnerabilities.critical }}operator:GreaterThanvalue:0第四步验证策略生效# 部署一个未签名或带高危漏洞的镜像应被拒绝kubectl apply-fpod-unsafe.yaml# Error from server: Pod pod-unsafe is forbidden: require-image-signature# 部署通过签名与漏洞校验的镜像正常创建kubectl apply-fpod-safe.yaml# pod/pod-safe created通过以上四步SBOM 提供了「镜像里有什么」的透明度Grype 负责「有没有已知漏洞」的检查Cosign 保证「内容未被篡改」Kyverno 则在部署入口强制落地这些策略形成从构建到运行的完整供应链安全闭环。使用可信基础镜像优先选择官方或经过安全审核的基础镜像并定期更新。锁定依赖版本使用锁文件如package-lock.json、go.sum固定依赖版本避免意外引入恶意版本。构建过程可复现使用多阶段构建、固定构建工具版本减少构建环境的不确定性。最小化镜像内容只保留运行所需的最小文件集减少攻击面。建立镜像策略通过 OPA、Kyverno 等策略引擎强制要求镜像必须通过扫描与签名校验才能部署。6. 端到端落地一条可信的镜像流水线将上述能力串联起来可以构建一条端到端的可信镜像流水线是否代码提交CI 构建镜像SBOM 生成镜像扫描存在高危漏洞?阻断并修复镜像签名推送镜像仓库部署前策略校验签名验证 漏洞复核准入运行7. 总结镜像安全不是单一工具能解决的问题而是扫描、签名、供应链治理三者协同的系统工程扫描解决「已知漏洞」问题是安全基线签名解决「内容可信」问题是防篡改保障供应链治理解决「源头可信」问题是长期防线。建议从「在 CI 中接入 Trivy 扫描」起步逐步引入 Cosign 签名与 Kyverno 准入校验再以 SBOM 完善供应链透明度。安全建设是持续演进的过程越早建立可信基线后续的运维与合规成本就越低。