TL;DR: GitHub Actions secret handling creates sprawl, weak rotation, and poor auditability as teams scale, and Infisical argues that native repository, environment, and org scopes cannot reliably enforce modern controls. The security model is now about ephemeral, identity-driven access rather than static credentials, because manual secret governance cannot keep pace with CI/CD growth.
NHIMG editorial — based on content published by Infisical: GitHub Actions secret sprawl and OIDC-based access
By the numbers:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: What breaks when GitHub Actions workflows are allowed to access secrets without approval?
A: When workflow secret access is not gated, an attacker can turn the CI runner into the exfiltration tool.
Q: When should teams move from static GitHub secrets to OIDC-based workflow access?
A: Teams should move when static credentials start to outlive the workflow job that needs them, or when access must be validated per execution rather than per repository.
Q: How do security teams know whether secrets in CI/CD are actually controlled?
A: Look for three signals: how many secrets a workflow can reach, how long those secrets remain valid, and whether any of them can publish or sign artefacts.
Practitioner guidance
- Centralize secret issuance in a source of truth Move CI/CD credentials out of scattered repository, environment, and organization settings into one managed system that owns rotation and revocation.
- Adopt OIDC for workflow authentication Use short-lived OIDC assertions to let GitHub Actions fetch runtime credentials without storing static secrets in the repository.
- Separate rotation from access visibility Track when a secret changes and which workflow consumed it, then require an audit record that can support incident scoping after a compromise.
What's in the full article
Infisical's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step configuration of GitHub Actions OIDC claims for repository and environment binding.
- Exact workflow YAML for pulling runtime credentials with Infisical/secrets-action.
- Implementation details for syncing secrets versus fetching them directly at runtime.
- Repository variable setup and runner-side export behaviour for deployment jobs.
👉 Read Infisical's analysis of GitHub Actions secret sprawl and OIDC-based access →
GitHub Actions secret sprawl: are your controls keeping up?
Explore further
Native CI/CD secrets create identity sprawl, not just secret sprawl: Once org, repo, and environment scopes accumulate, the real problem is no longer where a secret is stored but how many inheritance paths can reach it. That structure makes access reviews ambiguous and offboarding incomplete because the same credential can exist in multiple governance domains at once. The practitioner implication is that static placement inside GitHub is not a sufficient control boundary.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
A question worth separating out:
Q: What is the difference between secret masking and secret access control in GitHub Actions?
A: Secret masking hides values from logs, while access control determines who or what can obtain the credential in the first place. Masking reduces accidental exposure, but it does not stop an over-scoped workflow, repository user, or compromised runner from using the secret. Governance requires both controls, not one in place of the other.
👉 Read our full editorial: GitHub Actions secret sprawl and OIDC shift the trust model