GitHub CI Secret-Hardening Checklist

The fastest path from “someone can push a branch” to “someone stole our production secrets” runs through CI. Work the eight controls that stop secret exfiltration in GitHub Actions — least-privilege tokens, OIDC, environment protection, scoped secrets, no secret echo, SHA-pinned actions, reviewed workflows and an egress allowlist. Tap each to mark it in place, partial or not done, watch your coverage score, and export the result.

• Least-privilege GITHUB_TOKEN permissionsNot doneThe default GITHUB_TOKEN is broad. A workflow that only needs to read code should not be able to write packages, push commits or edit issues — the token a compromised job inherits is exactly the blast radius.How: Set org/repo default to read-only, then grant per-job scopes explicitly with a top-level or job-level permissions: block. Audit workflows that still rely on the default write-all token.
• OIDC federation instead of long-lived secretsNot doneA stored long-lived cloud key is a standing secret any job (or a pushed malicious workflow) can read and exfiltrate. OIDC mints a short-lived, workload-scoped token per run that is useless once the job ends.How: Configure the cloud/provider trust to accept GitHub’s OIDC issuer, scope the trust to specific repos/branches/environments, and delete the long-lived access keys you replace.
• Environment protection rules + required reviewersNot doneIn the LiteLLM compromise the production gate was approved with stolen tokens. A human reviewer who is distinct from the build identity is the control that a replayed token cannot satisfy on its own.How: Define protected environments (e.g. production) with required reviewers, a wait timer where useful, and deployment-branch restrictions. Keep approvers separate from the automation identity.
• Restrict secrets to protected branchesNot doneIf any branch can read production secrets, an attacker who can push a branch can read them. Scoping secrets to protected branches/environments means a throwaway branch workflow gets nothing worth stealing.How: Store deploy secrets as environment secrets on protected environments, not plain repo secrets, and restrict which branches may deploy to those environments.
• Forbid secret echo / set-output of secretsNot donePrinting a secret to logs, or passing it through set-output / step outputs, can leak it into log files, artifacts or downstream jobs where masking does not reach. Exfiltration is often just echo + a log read.How: Ban echoing secrets in review; rely on GitHub’s masking but never depend on it; never put a secret in an output or a build artifact. Lint workflows for secret interpolation into run: steps that print.
• Pin third-party actions to a full commit SHANot doneA tag like @v4 is mutable — the owner (or an attacker who compromises them) can repoint it to malicious code that then runs with your secrets. A full commit SHA is immutable.How: Replace uses: owner/action@v4 with uses: owner/action@<40-char-sha>. Automate with a pinning tool and review updates. Prefer first-party or well-reviewed actions.
• Review new / changed workflows in PRsNot doneA workflow file is code that runs with access to secrets the moment it lands on a triggering branch. The LiteLLM attacker pushed throwaway workflows to exfiltrate tokens — PR review of workflow changes is the gate on that.How: Require PR review and CODEOWNERS on the .github/workflows path, and require approval for workflows from fork pull requests before they run.
• Egress allowlist on runnersNot doneExfiltration needs an outbound destination — in the RCA, webhook.site. A runner that can POST to any host on the internet can ship secrets anywhere; an allowlist turns that into a blocked connection.How: Use runners (self-hosted or hardened) with egress filtering to a known allowlist of registries and endpoints, and alert on blocked outbound attempts as a signal.

Educational — not affiliated with GitHub, GitLab or any vendor. A self-assessment, not an audit. Runs entirely in your browser: nothing is uploaded and no scan is performed.