4. 发布包完整性概念

发布包完整性是云原生灾备与蓝绿发布中最容易被忽视、却影响最广的基础保障。一个字节的差异，就可能导致生产环境回滚、数据不一致甚至全量故障。本节从定义、破坏场景两个维度，建立完整性的系统认知。

4.1 完整性定义

发布包完整性指：从构建到部署的全链路中，发布包内容未被未授权修改、未发生比特级偏差、且所有依赖均正确关联。它由三个核心要素构成：

4.2 完整性破坏的常见场景

在实际的云原生灾备与蓝绿发布流程中，完整性破坏主要出现在以下三类场景：

4.2.1 传输错误

• 网络丢包/重传：TCP 层虽能恢复，但极端情况下（如中间件截断、代理缓存污染）仍可能产生静默损坏。
• 存储介质位翻转：磁盘、内存、SSD 的软错误（Soft Error）导致单比特翻转，尤其在长时间运行的 CI/CD 流水线中。
• 压缩/解压不一致：不同版本的 tar/gzip/zstd 工具对特殊文件（如硬链接、稀疏文件）处理存在差异。

4.2.2 篡改

• 中间人攻击：在镜像仓库、对象存储或包管理器的传输路径上，攻击者替换发布包内容。
• 供应链投毒：上游依赖被恶意修改，下游构建时自动拉取被篡改的组件。
• 内部越权：CI/CD 凭证泄露或内部人员直接修改制品仓库中的已有发布包。

4.2.3 依赖缺失

• 运行时依赖漂移：蓝绿发布中，新版本引用了旧环境已移除的共享库或系统包。
• 容器镜像层丢失：多阶段构建中，基础镜像层被 GC 清理或 registry 同步失败。
• Helm Chart 子依赖未锁定：Chart.lock 未提交，导致不同环境解析到不同版本的子 Chart。

4.3 完整性校验的层次模型

为了直观展示完整性校验在发布流程中的覆盖范围，下图以蓝绿发布为例，标注了每个环节的校验点：

4.4 完整性元数据示例

以下是一个标准的发布包完整性元数据片段（基于 in-toto 格式），展示了校验和、签名与依赖信息的关联方式：

{
  "payload": {
    "_type": "https://in-toto.io/Statement/v1",
    "subject": [
      {
        "name": "app-bluegreen-v2.3.1.tar.gz",
        "digest": {
          "sha256": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b"
        }
      }
    ],
    "predicateType": "https://slsa.dev/provenance/v1",
    "predicate": {
      "builder": { "id": "https://ci.example.com/builders/1" },
      "buildType": "https://example.com/Dockerfile+buildkit/v1",
      "materials": [
        {
          "uri": "git+https://git.example.com/repo.git@refs/tags/v2.3.1",
          "digest": { "sha1": "f1e2d3c4b5a6978b9c0d1e2f3a4b5c6d7e8f9a0b" }
        },
        {
          "uri": "docker://base-image@sha256:xyz...",
          "digest": { "sha256": "xyz..." }
        }
      ]
    }
  },
  "signatures": [
    {
      "keyid": "ABCDEF1234567890",
      "sig": "MEUCIQ..."
    }
  ]
}

4.5 完整性破坏的典型影响矩阵