如何在GitHub Pull Request Actions中防范恶意PR泄露密钥？

背景与问题 #

我需要在每个Pull Request上运行依赖外部API认证密钥的集成测试，当前的GitHub Actions工作流配置如下：

name: Pull Request Workflow
on:
  pull_request:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Build and test
        run: |
          # Build and test code here
          ./run-tests.sh --secret=$MY_SECRET
        # Use ${{ secrets.MY_SECRET }} to access the encrypted secret
        env:
          MY_SECRET: ${{ secrets.MY_SECRET }}

核心诉求是让贡献者能查看测试结果并修复问题，但存在风险：恶意贡献者可能篡改run-tests.sh脚本，将密钥发送给自己后发起PR。以下是几种可靠的密钥保护方案：

方案1：配置环境审批机制 #

将需要密钥的集成测试任务放到受保护的GitHub环境中，设置只有项目维护团队成员能审批触发该环境的任务。

工作流调整示例：

name: Pull Request Workflow
on:
  pull_request:
    branches:
      - main
jobs:
  # 先运行无密钥依赖的基础检查
  basic-check:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: 基础构建与单元测试
        run: ./basic-checks.sh

  # 依赖基础检查通过，且需审批后才能运行的集成测试
  integration-test:
    needs: basic-check
    environment:
      name: restricted-test-env
      url: https://your-test-report.example.com
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: 运行集成测试
        run: ./run-tests.sh --secret=$MY_SECRET
        env:
          MY_SECRET: ${{ secrets.MY_SECRET }}

这种方式下，恶意PR无法直接触发带密钥的测试，必须经过维护者审批后才会注入密钥执行，从流程上阻断密钥泄露风险。

方案2：限制Secrets对fork PR的访问 #

GitHub默认不会给来自外部fork仓库的PR注入仓库Secrets，只有同一仓库分支的PR，或维护者手动批准fork PR的Secrets访问权限时，Secrets才会生效。针对外部贡献者的PR：

• 可由维护者在本地运行集成测试，将结果反馈给贡献者；
• 若要自动运行测试，可改用pull_request_target事件替代pull_request：该事件会checkout主分支（而非PR分支）的代码执行工作流，避免运行PR分支的恶意脚本，同时安全注入Secrets。注意使用时必须严格控制代码checkout逻辑，绝对不要执行PR分支的未审核代码。

方案3：隔离可信测试脚本 #

将run-tests.sh放在受保护的主分支中，禁止外部贡献者修改；工作流中固定从主分支拉取该脚本，而非使用PR分支的版本：

- name: 拉取主分支的可信测试脚本
  run: |
    git fetch origin main:temp-main
    git checkout temp-main -- run-tests.sh
    git checkout -
- name: 运行集成测试
  run: ./run-tests.sh
  env:
    MY_SECRET: ${{ secrets.MY_SECRET }}

即使PR篡改了自身分支的run-tests.sh，工作流依然使用主分支的可信版本，从根源上避免密钥被恶意脚本窃取。

方案4：使用权限受限的专用密钥 #

为集成测试创建独立的API密钥，严格限制其权限：比如仅允许访问测试环境、设置只读权限、限制调用次数与有效期。这样即使密钥意外泄露，也只会造成极小的范围影响，不会威胁生产环境的安全。

内容的提问来源于stack exchange，提问作者Ben Hirschberg