Selective Secret Exposure for Forked Pull Requests

Answer

GitHub Actions already provides mechanisms that can expose read‑only secrets to forked pull requests when combined with explicit safeguards.

Confirmed facts

• Secrets (except GITHUB_TOKEN) are hidden for pull_request events from forks.
• The pull_request_target event runs in the base repository context and retains access to all secrets.
• Environment protection rules can require manual approval or specific branches before a job may use secrets.
• A workflow_run trigger can execute a separate workflow after the PR closes/merges, granting secret access without running untrusted code.

Likely explanation / recommended approach

1. Use a workflow that triggers on pull_request_target.
2. Place the job that needs secrets inside an environment (e.g., secret-env) that has required reviewers configured.
3. Require at least one approved review from a repository maintainer before the job can start; this blocks untrusted code from accessing secrets.
4. If immediate feedback is not required, alternatively use a workflow_run workflow that runs after the PR is merged or closed to perform secret‑dependent steps.

Steps to verify the setup

# 1. Create a test secret (e.g., TEST_SECRET) in the repository Settings → Secrets → Actions.
# 2. Add a workflow file .github/workflows/fork-secret-test.yml:
name: Fork secret test
on:
  pull_request_target:
    types: [opened, synchronize, reopened]
jobs:
  show-secret:
    runs-on: ubuntu-latest
    environment: secret-env   # reference the environment you will configure
    steps:
      - name: Echo secret (masked)
        run: echo \"${{ secrets.TEST_SECRET }}\"

1. Go to Settings → Environments, create secret-env and enable Required reviewers (add a trusted user or team).
2. Fork the repository, open a pull request, and observe that the job pauses waiting for approval.
3. After an approved reviewer approves, the job runs and the secret appears masked (***) in the log, confirming access.
4. Check the repository Settings → Actions → General → "Allow GitHub Actions to create and approve pull requests" – this setting is unrelated to secret exposure but should be left disabled unless you intentionally want the bot to approve.

Future plans

As of the June 2024 knowledge cutoff, GitHub has not announced a dedicated toggle or configuration option for selective read‑only secret exposure to forked PRs. Any such feature would be speculative and would need to undergo security review.

Security implications vs benefits

• Risk: Exposing any secret to a forked PR allows the fork’s code to read it; if the workflow runs untrusted code (e.g., without approvals) the secret could be leaked.
• Mitigation: Using pull_request_target with environment approvals or restricting to trusted branches ensures that only vetted code can access secrets.
• Benefit: Developers in forks can receive accurate test results that depend on secrets (e.g., API keys for integration tests) without needing to duplicate those secrets locally, reducing configuration drift.
• Trade‑off: The mitigation adds latency (waiting for approval) and relies on reviewer diligence; for low‑risk secrets or internal projects the added friction may be unnecessary.

If you need immediate feedback and cannot wait for manual approval, consider whether the secret can be replaced with a read‑only token scoped to the fork (e.g., a limited‑scope personal access token) or whether the workflow can be split into a public‑only lint step and a secret‑dependent step that runs on workflow_run after merge.