How do you manage secrets and environments in GitHub Actions securely?

Managing secrets in CI/CD is like handling the keys to a bank vault. You do not give every employee the master key — instead, you issue role-specific access cards (scoped secrets), require two-person authorization for the vault room (environment protection rules), rotate the cards regularly (secret rotation), and install cameras that blur the card numbers in footage (log masking). GitHub Actions implements all these layers, and understanding how they compose is critical for a secure pipeline.

GitHub encrypts secrets at rest using libsodium sealed boxes and only decrypts them at runtime on the runner. Secrets exist at three scopes: organization (shared across repos via access policies), repository (available to all workflows in the repo), and environment (only available when a job targets that specific environment). When scopes overlap, the most specific wins — an environment secret named API_KEY overrides a repository secret with the same name. Secrets are injected as environment variables or interpolated via ${{ secrets.NAME }}, and the runner's log processor automatically masks any value matching a known secret, replacing it with '***'. However, this masking is best-effort — if you base64-encode a secret or split it across multiple log lines, the mask fails.

Internally, the secrets delivery mechanism works through a secure channel between GitHub's control plane and the runner agent. When a job starts, the orchestrator evaluates which secrets the job is entitled to based on its environment, repository, and organization membership. It encrypts the relevant secrets with the runner's session key and transmits them over TLS. On the runner, secrets exist only in memory and are purged after the job completes. For fork pull requests, repository secrets are deliberately withheld to prevent exfiltration by malicious PRs — only the GITHUB_TOKEN with limited permissions is available. The 'pull_request_target' trigger, which runs in the context of the base branch, does have access to secrets, but using it carelessly with code from the PR creates a critical injection vulnerability.

In production environments, the gold standard is eliminating static secrets entirely using OIDC (OpenID Connect) federation. GitHub Actions can mint short-lived OIDC tokens containing claims about the workflow, repository, and branch. Cloud providers like AWS, GCP, and Azure validate these tokens and issue temporary credentials — no stored secrets needed. For secrets that must remain static (API keys, license keys), implement rotation via GitHub's API, store them at the environment level with required reviewers for production, and use organization-level secrets for shared infrastructure credentials. Environment protection rules add human approval gates, wait timers (useful for blue-green deployments), and branch restrictions ensuring only the main branch can deploy to production. Combine this with deployment branch policies and the deployment status API for full audit trails.

The most dangerous gotcha is the 'pull_request_target' trigger combined with an explicit checkout of the PR's head — this gives the PR's untrusted code access to all repository secrets. Another common mistake is logging secrets indirectly: running 'curl -v' with an Authorization header will print the secret in verbose output before the masker can catch it. Environment variables containing secrets should never be passed to untrusted scripts or actions without vetting. Also, the GITHUB_TOKEN's default permissions vary by repository settings — in newer repos it defaults to read-only, but in older repos it may still have broad write permissions. Always explicitly declare the minimum permissions needed using the 'permissions' key at the workflow or job level.