GitHub Actions 中 Miri 缓存导致秘密泄露的风险与防护

在持续集成与持续部署（CI/CD）流程中，构建速度的优化至关重要。GitHub Actions 提供的缓存功能，允许我们存储和复用构建过程中的中间产物，如依赖包、编译结果等，从而显著缩短后续运行的时间。然而，当我们在流程中引入像 Miri 这样的内存安全检测工具时，缓存的使用方式可能无意中成为秘密泄露的渠道。

原理要点

Miri 是 Rust 语言官方提供的内存安全检测工具，它通过模拟运行时环境来检测潜在的内存错误。在 GitHub Actions 中运行 Miri 时，通常会执行一个耗时的检查过程。为了加速后续运行，工程师可能会缓存 Miri 的输出或相关状态。

问题的核心在于：缓存的内容是什么？缓存键（key）是如何生成的？

如果缓存键或缓存路径中包含了敏感信息，或者缓存的文件本身记录了包含秘密的环境变量、配置值、文件路径等，那么这些信息就会被持久化到缓存中。一旦缓存被意外共享、访问或泄露（例如，在公共仓库中，缓存可能被其他工作流或分支间接访问），秘密就可能暴露。

常见的泄露途径包括：

1. 缓存键包含秘密：使用包含令牌、密钥或特定环境变量的值作为缓存键的一部分。
2. 缓存路径包含秘密：将包含敏感信息的环境变量或配置写入缓存目录。
3. Miri 输出记录秘密：Miri 在运行过程中，其日志或输出文件可能意外记录了环境变量、命令行参数或文件路径，这些内容被缓存下来。

实战步骤

以下是一个通用的 GitHub Actions 工作流示例，展示了如何安全地使用 Miri 缓存。

错误示例：存在泄露风险

name: Rust Miri Check
on: [push]

jobs:
  miri-check:
    runs-on: ubuntu-latest
    env:
      MY_SECRET_TOKEN: ${{ secrets.MY_SECRET_TOKEN }}
    steps:
      - uses: actions/checkout@v4

      - name: Setup Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable
          components: miri

      - name: Cache Miri output
        uses: actions/cache@v4
        with:
          # 危险：缓存键直接使用了包含秘密的环境变量
          key: ${{ runner.os }}-miri-${{ env.MY_SECRET_TOKEN }}-${{ hashFiles('**/Cargo.lock') }}
          restore-keys: |
            ${{ runner.os }}-miri-
          path: ~/.cargo/registry

      - name: Run Miri
        run: cargo miri test

在这个示例中，缓存键 key 直接使用了 MY_SECRET_TOKEN 环境变量。这意味着秘密令牌被用作缓存标识的一部分，并可能以某种形式被写入缓存系统或日志中，构成泄露风险。

正确示例：安全的缓存实践

name: Rust Miri Check
on: [push]

jobs:
  miri-check:
    runs-on: ubuntu-latest
    env:
      MY_SECRET_TOKEN: ${{ secrets.MY_SECRET_TOKEN }}
    steps:
      - uses: actions/checkout@v4

      - name: Setup Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable
          components: miri

      - name: Cache Miri output (Safe)
        uses: actions/cache@v4
        with:
          # 安全：缓存键仅使用非敏感信息
          key: ${{ runner.os }}-miri-${{ hashFiles('**/Cargo.lock') }}
          restore-keys: |
            ${{ runner.os }}-miri-
          # 明确指定缓存路径，避免缓存无关的敏感目录
          path: |
            ~/.cargo/registry
            ~/.cargo/git

      - name: Run Miri
        # 确保 Miri 运行时不会将秘密信息输出到可能被缓存的日志中
        run: |
          # 可以设置环境变量来抑制某些输出，或检查 Miri 日志格式
          cargo miri test

关键改进点：

1. 缓存键纯化：缓存键只使用操作系统、文件哈希等非敏感信息。
2. 缓存路径明确：明确指定需要缓存的路径（如 Cargo 的 registry 和 git 目录），避免缓存整个用户目录或可能包含秘密的临时目录。
3. 输出审查：了解 Miri 的输出内容，确保其不会记录敏感环境变量或配置。可以通过检查 Miri 的文档或运行测试来确认。

常见坑与排查清单

1. 坑：缓存键自动生成包含秘密
   • 排查：检查所有 actions/cache 步骤的 key 字段。确保其中没有引用 secrets、env 中可能包含秘密的变量，或任何用户输入。
   • 对策：使用 hashFiles 函数基于源代码文件生成键，或仅使用 runner.os 和固定字符串。
2. 坑：缓存路径过大或包含敏感目录
   • 排查：检查 path 字段。避免使用 ~/.cargo 或 ~/.github 等可能包含秘密配置或令牌的路径。
   • 对策：精确指定需要缓存的子目录，如 ~/.cargo/registry。对于其他可能包含秘密的目录（如 .env 文件所在目录），绝对不要缓存。
3. 坑：工具输出日志泄露秘密
   • 排查：运行工具时，检查其输出日志。特别是当工具被缓存时，其输出可能被保存。
   • 对策：查阅工具文档，了解其日志行为。对于 Miri，可以关注其是否输出环境变量。必要时，在运行前清理或屏蔽敏感环境变量。
4. 坑：缓存权限与访问控制
   • 排查：在公共仓库中，缓存可能被任何工作流访问。在私有仓库中，检查仓库设置中的缓存权限。
   • 对策：对于高度敏感的项目，考虑禁用缓存，或使用更严格的访问控制策略（如果平台支持）。
5. 坑：本地测试与 CI 行为不一致
   • 排查：在本地模拟 CI 环境时，可能忽略了缓存键或路径的差异。
   • 对策：使用与 CI 相同的环境变量和配置进行本地测试，确保缓存行为一致。

小结

在 CI/CD 流程中利用缓存提升效率时，安全考量必须同步跟进。对于 GitHub Actions 中 Miri 缓存的场景，核心原则是：缓存键和缓存路径必须与秘密信息隔离。通过纯化缓存键、明确缓存路径、审查工具输出，我们可以有效避免因缓存机制导致的秘密泄露风险。工程师在优化构建性能的同时，应始终保持对数据流动和安全边界的警惕。