1. 信任边界概述：镜像供应链信任边界的定义、为什么需要信任边界、信任边界在 DevSecOps 中的位置
1.1 镜像供应链信任边界的定义
在云原生环境中，镜像供应链信任边界是指从代码提交、镜像构建、制品存储、安全扫描、签名分发到运行时部署这一完整链路中，组织所设定的安全信任分界点。它明确了“谁在什么阶段、以何种权限、对镜像内容负责”，以及“在哪些环节必须进行验证与授权”。
信任边界并非物理隔离，而是逻辑与策略的集合，通常包含以下核心要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 身份主体 | 可执行操作的用户、服务账号或 CI/CD 系统 | 开发者、Jenkins 服务、Kubernetes kubelet |
| 信任锚点 | 用于验证镜像真实性与完整性的根凭证 | 私钥签名、Notary 根密钥、TUF 根元数据 |
| 策略规则 | 定义哪些镜像可被信任、哪些必须拒绝 | 仅允许签名镜像、禁止 latest 标签、强制 SBOM 附随 |
| 验证节点 | 执行信任检查的网关或准入控制器 | 镜像仓库策略引擎、Kubernetes Admission Webhook |
| 审计日志 | 记录信任决策的完整证据链 | Sigstore Rekor 透明日志、仓库操作日志 |
关键认知：信任边界不是“信任所有人”，而是“在边界内默认信任，在边界外必须验证”。边界内的操作受策略约束，边界外的镜像默认不可信。
1.2 为什么需要信任边界
镜像供应链面临多种攻击向量，没有信任边界将导致以下风险：
- 投毒攻击：攻击者向基础镜像或依赖层注入恶意代码，如 2021 年发现的
dependency confusion攻击。 - 篡改攻击：镜像在传输或存储过程中被替换，例如中间人攻击篡改仓库中的镜像摘要。
- 未授权发布：开发者绕过安全扫描直接将镜像推送到生产仓库。
- 依赖链污染：上游基础镜像或第三方库被植入后门，下游镜像继承风险。
建立信任边界带来的核心收益：
- 最小化攻击面：只有通过验证的镜像才能进入生产环境，阻断未签名或来源不明的镜像。
- 可追溯性：每个镜像的构建、签名、分发环节都有记录，便于审计与取证。
- 策略即代码：信任规则可版本化管理，与 CI/CD 流程集成，实现自动化合规。
- 供应链韧性：即使上游仓库被攻破，信任边界仍能阻止恶意镜像扩散。
行业参考：CNCF 发布的《Software Supply Chain Best Practices》明确将“定义信任边界”列为镜像安全治理的首要步骤。SLSA（Supply-chain Levels for Software Artifacts）框架也以信任边界作为等级划分的基础。
1.3 信任边界在 DevSecOps 中的位置
在 DevSecOps 流水线中，信任边界贯穿开发、构建、分发、部署四个阶段，是安全左移与运行时防护的衔接点。下图展示了信任边界在典型镜像供应链中的位置：
上图展示了信任边界如何将镜像供应链划分为操作层与验证层。在 DevSecOps 实践中，信任边界通常部署在以下关键位置：
| 流水线阶段 | 信任边界位置 | 典型工具/机制 |
|---|---|---|
| 代码提交 | 开发者本地 → 代码仓库 | GPG 签名、Signed Commits |
| 镜像构建 | CI 系统 → 镜像仓库 | Cosign 签名、Notary v2 |
| 镜像分发 | 镜像仓库 → 部署集群 | OCI 分发规范、Ratify 策略引擎 |
| 运行时部署 | Kubernetes API → Pod 创建 | Kyverno / OPA Gatekeeper 准入控制 |
常见误区：许多团队只在部署阶段设置准入控制，忽略了构建与分发阶段的信任边界。这会导致“信任盲区”——镜像在进入仓库前可能已被篡改，而准入控制只能检查仓库中的状态，无法追溯构建过程。
1.4 信任边界的核心原则
在配置镜像供应链信任边界时，应遵循以下原则：
- 最小信任原则：默认不信任任何镜像，除非通过显式策略验证。
- 持续验证原则：信任不是一次性的，每次拉取、部署都应重新验证。
- 不可否认原则：所有信任决策必须记录在不可篡改的日志中。
- 策略分层原则：不同环境（开发、测试、生产）应有不同的信任阈值。
下表对比了“无信任边界”与“有信任边界”的镜像供应链安全状态：
| 维度 | 无信任边界 | 有信任边界 |
|---|---|---|
| 镜像来源 | 任何仓库均可拉取 | 仅允许授权仓库 |
| 镜像完整性 | 依赖传输层安全 | 签名+摘要双重验证 |
| 策略执行 | 人工审核 | 自动化准入控制 |
| 审计能力 | 日志分散、难以追溯 | 透明日志+不可篡改记录 |
| 应急响应 | 手动下线镜像 | 策略阻断+自动回滚 |