2. 信任边界驱动开发（TBDD）方法论

信任边界驱动开发（Trust Boundary Driven Development，TBDD）是一种将安全信任决策前置到软件设计阶段的方法论。它要求开发团队在编写第一行代码之前，先明确系统中哪些组件是“可信的”、哪些是“不可信的”，以及数据跨越信任边界时应当执行哪些验证与授权策略。TBDD 将安全从“事后修补”转变为“设计内置”，尤其适用于容器镜像供应链场景——每个镜像层、每个基础镜像来源、每个 CI/CD 阶段都可能构成一条信任边界。

2.1 TBDD 核心原则

TBDD 建立在以下四条核心原则之上，这些原则直接指导 Cosign 签名与验证策略的设计：

原则 定义 在镜像供应链中的体现
信任最小化 默认不信任任何外部输入或组件，直到其身份和完整性被验证 所有基础镜像、第三方依赖、CI 产物在进入流水线前必须经过 Cosign 签名验证
边界显式化 在架构图中明确标注信任边界的位置和跨越方向 在 Kubernetes 部署清单中声明镜像签名策略，使用 ClusterImagePolicy 定义边界
策略即代码 信任决策必须通过可审计的策略规则表达，而非人工判断 使用 cosign verify 与 Rego 策略结合，实现自动化准入控制
持续验证 信任不是一次性的；每次使用或部署时都必须重新验证 在拉取、构建、部署、运行时各阶段分别执行 Cosign 验证，形成验证链
实践要点： 在实施 TBDD 时，建议从“最危险的边界”开始——即外部镜像进入内部仓库的那条边界。先为这条边界配置 Cosign 强制验证，再逐步向内层推进。

2.2 与传统 DevSecOps 的区别

TBDD 并非对 DevSecOps 的否定，而是在其基础上增加了“信任边界”这一显式设计维度。下表对比了两者在关键维度上的差异：

维度 传统 DevSecOps TBDD
安全介入时机 通常在 CI/CD 流水线中插入安全扫描步骤 在设计阶段即定义信任边界，安全策略与架构同步演进
信任模型 隐式信任内部组件，仅对外部输入做检查 默认零信任，所有组件跨越边界时都必须验证
策略粒度 全局统一的安全策略，缺乏上下文感知 按边界划分策略，不同边界可应用不同验证强度
失败模式 扫描发现问题后告警，但构建可能继续 信任验证失败则阻断流水线，不允许未签名镜像进入下一阶段
可审计性 依赖日志和事后分析 策略即代码，签名链可追溯，每次验证都有密码学证据
关键区别总结： DevSecOps 回答“我们是否做了安全检查？”，TBDD 回答“我们是否知道谁应该被信任，以及信任的边界在哪里？”。后者将安全从“活动”提升为“架构属性”。

2.3 信任边界定义与划分

在镜像供应链中，信任边界是数据或控制权从一个信任域转移到另一个信任域的点。正确划分信任边界是 TBDD 的核心技能。以下是在容器镜像场景中常见的五类信任边界：

  1. 开发者工作站 → 代码仓库：开发者提交的代码是否经过签名？提交者身份是否可验证？
  2. 代码仓库 → CI/CD 流水线：流水线触发时，是否验证了代码来源和提交者签名？
  3. CI/CD 流水线 → 镜像仓库：构建后的镜像是否由可信构建系统签名？是否防止了中间人替换？
  4. 镜像仓库 → 部署环境：Kubernetes 集群在拉取镜像时，是否验证了镜像签名和策略？
  5. 运行时 → 外部依赖：容器运行时是否验证了挂载卷、网络策略和 sidecar 镜像的完整性？

下图展示了镜像供应链中典型的信任边界划分，以及 Cosign 在每个边界上的验证作用点：

镜像供应链信任边界划分与 Cosign 验证点 镜像供应链信任边界划分与 Cosign 验证点 开发者工作站 代码签名 代码仓库 提交验证 CI/CD 流水线 镜像签名 镜像仓库 存储验证 部署环境 准入控制 边界1 边界2 边界3 边界4 Cosign 在各信任边界的验证策略 • 边界1: cosign sign-blob 对代码提交签名 • 边界2: cosign verify-blob 验证提交来源 • 边界3: cosign sign 对镜像签名 + cosign attest 添加 SBOM 证明 • 边界4: cosign verify 在拉取时验证签名 • 运行时: ClusterImagePolicy + Kyverno 准入控制 信任边界划分原则：每跨越一条边界，信任等级必须重新建立 不可信 → 半可信 → 可信 → 高可信，逐级验证，不可跳过

2.4 信任边界划分的实践方法

在实际项目中，划分信任边界需要结合架构图与数据流分析。推荐采用以下四步法：

  • 步骤1：绘制组件依赖图 —— 列出所有参与镜像构建、分发、部署的组件（开发者、CI 系统、仓库、集群等）。
  • 步骤2：标注数据流向 —— 用箭头标出镜像、配置、凭证的流动方向，识别每个“接收方”是否完全信任“发送方”。
  • 步骤3：标记信任边界 —— 在每次信任关系发生变化的位置画一条虚线，即为信任边界。
  • 步骤4：为每条边界分配验证策略 —— 根据边界风险等级选择 Cosign 验证方式（签名验证、证明验证、策略引擎）。
常见误区： 不要将“内部网络”等同于“可信”。即使在同一 Kubernetes 集群内，不同命名空间之间的镜像拉取也应视为跨越信任边界。始终假设网络不可信，除非有密码学证据证明身份。

2.5 TBDD 与 Cosign 的结合点

Cosign 为 TBDD 提供了密码学层面的信任锚点。下表展示了 TBDD 的每条原则如何映射到 Cosign 的具体功能：

TBDD 原则 Cosign 功能 配置示例
信任最小化 cosign verify 强制验证签名 
cosign verify --key cosign.pub myrepo/myimage:latest
边界显式化 ClusterImagePolicy 定义边界策略 
apiVersion: cosign.sigstore.dev/v1beta1
kind: ClusterImagePolicy
spec:
  images:
  - glob: "myregistry.io/*"
  authorities:
  - key:
      data: "..."
策略即代码 Cosign + Rego 策略引擎 
cosign verify --policy policy.rego myimage
持续验证 Cosign 在拉取、部署、运行时多次验证 
# 拉取时验证
crane copy --cosign-verify=true
# 部署时验证
kubectl apply --cosign-verify=true
← 上一章 📖 返回目录 下一章 →