2. 镜像供应链安全基础：镜像分层原理、基础镜像来源与SBOM概念
在K8s集群升级前，镜像供应链安全是必须优先评估的环节。镜像不仅是应用运行时的载体，更是操作系统依赖、第三方库、配置文件的集合体。一旦镜像供应链被污染，升级后的集群将面临从底层到应用层的全面风险。本节从镜像分层原理、基础镜像来源、软件物料清单（SBOM）三个核心维度建立安全基础认知。
2.1 镜像分层原理与安全影响
Docker/OCI镜像由多个只读层（Layer）堆叠而成，每一层对应Dockerfile中的一条指令。分层机制实现了存储复用与增量传输，但也引入了供应链安全风险：每一层都可能引入漏洞、恶意文件或配置漂移。
关键安全认知： 镜像的最终安全水位取决于最薄弱的一层。即使应用层完全安全，只要基础层或中间层存在已知漏洞（CVE），整个镜像即视为不安全。
运维检查要点： 在升级前，应使用
docker history --no-trunc <image> 或 skopeo inspect 查看镜像分层历史，确认每一层的大小、创建指令和基础镜像来源。异常大的层或非预期的 ADD 指令往往是供应链攻击的入口。
2.2 基础镜像来源与可信度分级
基础镜像是镜像供应链的根。根据来源的可信度与维护水平，可将基础镜像分为四个等级。K8s集群升级前，必须对集群中所有工作负载的基础镜像来源进行审计。
| 等级 | 来源类型 | 典型示例 | 安全风险 | 升级前建议 |
|---|---|---|---|---|
| L1 | 官方发行版 + 官方签名 | ubuntu:22.04, alpine:3.18, registry.k8s.io/pause:3.9 | 低（有CVE跟踪和及时修复） | 优先使用，锁定摘要（digest） |
| L2 | 官方认证镜像（Red Hat、SUSE、Chainguard） | registry.access.redhat.com/ubi9, cgr.dev/chainguard/static | 低-中（经过安全扫描，但版本可能滞后） | 验证签名与SBOM |
| L3 | 社区维护镜像（Docker Hub、GitHub Container Registry） | node:20-slim, python:3.11-slim | 中-高（维护者水平参差，更新不及时） | 必须扫描CVE，重建最小化镜像 |
| L4 | 第三方或个人构建镜像 | 任意非官方仓库中的镜像 | 高（无审计、无签名、可能植入后门） | 禁止直接使用，必须从源码重建 |
升级前红线： 集群中若存在L4级基础镜像，必须立即标记并替换。L3级镜像必须通过CVE扫描且高危漏洞清零后方可进入升级流程。L1/L2级镜像建议锁定至具体摘要（digest），避免使用可变标签（如
:latest）。
2.3 软件物料清单（SBOM）概念与生成
SBOM（Software Bill of Materials）是镜像中所有软件组件的结构化清单，包含组件名称、版本、许可证、依赖关系及来源信息。在K8s升级前，SBOM是判断镜像是否包含已知漏洞、许可证冲突或恶意组件的核心依据。
2.3.1 SBOM的核心字段
| 字段 | 说明 | 示例值 |
|---|---|---|
| 组件名称 | 软件包或库的标识 | openssl, requests, log4j-core |
| 版本号 | 精确版本，含补丁级别 | 3.0.8, 2.31.0, 2.17.1 |
| 许可证 | 开源许可证类型 | Apache-2.0, MIT, GPL-3.0 |
| 来源URL | 组件下载或仓库地址 | https://pypi.org/project/requests/ |
| 依赖关系 | 该组件依赖的其他组件 | cryptography, idna, certifi |
| 哈希值 | 组件文件的完整性校验 | sha256:abc123... |
2.3.2 SBOM生成工具与格式
目前业界主流使用 SPDX 和 CycloneDX 两种标准格式。推荐在CI/CD流水线中集成SBOM生成，并在镜像仓库中与镜像一同存储。
# 使用 syft 生成 CycloneDX 格式的 SBOM
syft packages your-image:tag -o cyclonedx-json > sbom.cyclonedx.json
# 使用 trivy 生成 SPDX 格式的 SBOM
trivy image --format spdx-json --output sbom.spdx.json your-image:tag
# 验证 SBOM 与镜像的一致性（cosign）
cosign verify-attestation --type spdx your-image:tag
升级前SBOM检查清单：
- 每个即将升级的节点上运行的镜像是否都有对应的SBOM？
- SBOM中是否存在已知的高危/严重CVE（CVSS ≥ 7.0）？
- SBOM中是否包含已被标记为恶意或废弃的组件？
- SBOM中的许可证是否与组织合规策略冲突（如GPL-3.0在商业闭源产品中）？
- SBOM的生成时间是否在镜像构建后的合理窗口内（建议不超过24小时）？
2.4 镜像供应链安全水位评估指标
在K8s集群升级前，建议使用以下量化指标评估镜像供应链安全水位，并设定最低准入阈值。
| 指标 | 计算公式 | 安全阈值（升级前必须满足） |
|---|---|---|
| SBOM覆盖率 | 有SBOM的镜像数 / 总镜像数 × 100% | ≥ 95% |
| 基础镜像可信率 | L1+L2级基础镜像数 / 总镜像数 × 100% | ≥ 90% |
| 高危CVE清零率 | 无高危CVE的镜像数 / 总镜像数 × 100% | 100% |
| 镜像签名率 | 已签名的镜像数 / 总镜像数 × 100% | ≥ 80%（建议100%） |
| 镜像年龄（天） | 当前时间 - 镜像构建时间 | ≤ 30天（生产环境） |
实操建议： 使用
oras 或 crane 工具批量拉取镜像的SBOM和签名信息，结合 grype 或 trivy 进行离线CVE扫描。将扫描结果汇总为JSON报告，导入到集群的 策略引擎（如OPA/Gatekeeper） 中，实现升级前的自动化准入校验。