GitHub Actions secret sprawl and OIDC shift the trust model

At a glance

What this is: This article argues that native GitHub Actions secrets do not scale cleanly and that OIDC-backed, centrally managed secrets change the trust model for CI/CD credentials.

Why it matters: It matters because IAM, PAM, and NHI teams need auditable, short-lived access patterns in build pipelines, not scattered static credentials that drift across repositories and environments.

By the numbers:

• 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.
• 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.

👉 Read Infisical's analysis of GitHub Actions secret sprawl and OIDC-based access

Context

GitHub Actions depends on credentials to build, test, and deploy software, but native secrets management becomes fragile as repository count, environment count, and release velocity grow. The primary governance problem is not log masking alone. It is whether a secret can be scoped, rotated, revoked, and audited consistently across the CI/CD estate, which is a core NHI management concern.

The article frames GitHub’s built-in secrets model as workable for small teams but increasingly difficult to govern at scale. It also introduces a different trust pattern through OIDC federation and external secret management, where the workflow uses ephemeral access instead of long-lived static credentials. That shift is directly relevant to teams responsible for workload identity, secret lifecycle, and access review discipline.

Key questions

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. A malicious workflow can dump secrets, upload them as an artifact, and remove traces before anyone notices. At that point, detection becomes reactive only, and organisations are left rotating credentials after exposure instead of preventing the theft in the first place.

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. OIDC is the better fit when the workflow identity can be asserted at runtime and the organisation needs zero standing privilege for build access.

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. If a build job can touch long-lived credentials or production systems, the environment is not controlled. The objective is to reduce reachable secrets and shorten exposure windows.

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.

Technical breakdown

Why native GitHub secrets become secret sprawl

GitHub Secrets are encrypted and hidden from logs, but they still live inside a hierarchy of org, repository, and environment scopes. As that hierarchy expands, access decisions become inherited, duplicated, and difficult to reason about. Secret sprawl appears when the same credential is copied into multiple scopes, rotation becomes manual, and teams lose track of where each secret is actually used. The technical issue is not just storage. It is uncontrolled propagation across a federated developer platform.

Practical implication: Treat GitHub-native secret scope expansion as a lifecycle problem, not just a storage problem.

Why rotation and auditability matter in CI/CD credentials

A credential that cannot be rotated automatically remains live long after it should have been retired. In GitHub Actions, the absence of a native access trail means teams can often see that a secret exists, but not reliably who used it, from where, or in which job execution. That makes incident scoping slow and revocation decisions reactive. In practice, the longer a secret persists, the wider the blast radius if the repository, runner, or workflow is compromised.

Practical implication: Map every pipeline secret to a rotation owner and an auditable access source of truth.

How OIDC changes GitHub Actions authentication

OpenID Connect replaces stored secrets with short-lived assertions about the workflow identity. GitHub signs a JWT with claims such as issuer, subject, repository, and environment, and the external secret manager validates those claims before issuing access. This is a materially different control model from repository-scoped secrets because the credential is not pre-positioned in the workflow. Instead, access is derived at runtime from identity context, which better supports ephemeral execution and tighter policy boundaries.

Practical implication: Use OIDC where the workflow identity can be validated at runtime instead of preloading static credentials.

Threat narrative

Attacker objective: Abuse long-lived CI/CD credentials to move through build and deployment workflows without immediate detection or revocation.

1. Entry begins when secrets are copied into GitHub org, repository, or environment scopes, which creates multiple places for exposure and reuse.
2. Escalation occurs when a leaked or over-scoped credential survives because native GitHub secrets do not provide automated rotation or a durable access trail.
3. Impact follows when an attacker or unauthorized workflow abuses the credential across deployments, with limited visibility into which secrets were accessed or how far the abuse spread.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Rotation without audit is only partial control: The article is right to separate automated rotation from access visibility. A secret that can be rotated but not reliably audited still leaves incident responders guessing when abuse begins and ends. This is exactly where lifecycle governance and PAM expectations collide with CI/CD reality, because the control objective is not only to change the value but to know which runtime consumed it.

Ephemeral workflow authentication changes the governance model: OIDC-backed access moves the trust decision from stored credential possession to runtime identity validation. That aligns better with zero standing privilege than with static secret reuse, but only if claims, repository context, and environment boundaries are enforced precisely. The practitioner conclusion is that build pipelines should be governed like short-lived machine identities, not like configuration files.

Secret sprawl is a source-of-truth failure: When the same credential is managed across GitHub, a vault, and multiple deployment environments, accountability fragments unless one system owns issuance and revocation. The article points to the need for a single control plane for secret lifecycle, because distributed secret management without authoritative ownership guarantees drift. Teams should treat that drift as an identity governance defect, not a tooling inconvenience.

From our research:

• 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.
• Use NHI Lifecycle Management Guide to connect rotation, revocation, and offboarding into one governed lifecycle.

What this signals

Secret lifecycle control now matters more than secret placement: The shift from native GitHub storage to external OIDC-backed retrieval shows that pipeline credentials need issuance, rotation, revocation, and audit under one lifecycle. That is a workload identity problem as much as a secrets problem, and it belongs in the same governance model as other non-human identities. For practitioners, the key question is whether the current control plane can prove who used a credential and when.

Private repositories are not a safe assumption for secret hygiene: GitGuardian's 2026 data shows that internal repositories are 6x more likely to contain secrets than public ones, which means exposure risk is often created inside normal engineering process rather than through obvious leakage paths. That should push teams to measure hidden privilege, not just public exposure. The practical next step is to treat every build pipeline as a governed identity surface, not a storage convenience.

Zero standing privilege should extend into CI/CD: When credentials only exist for the duration of a job step, the pipeline starts to resemble a controlled machine identity rather than a repository artifact. That is the right direction for teams aligning with NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10. The governance signal is simple: if your pipeline still depends on long-lived static secrets, your access model is lagging your delivery model.

For practitioners

• 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. The goal is to eliminate duplicate credential states across the pipeline estate.
• Adopt OIDC for workflow authentication Use short-lived OIDC assertions to let GitHub Actions fetch runtime credentials without storing static secrets in the repository. Enforce claim checks for repository, environment, and workflow context before issuing access.
• 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. Rotation alone does not answer who used the credential last.
• Review secret scope inheritance Audit org, repo, and environment inheritance paths to find credentials that are reachable from more jobs than intended. Reduce scope overlap wherever a workflow can inherit a broader secret than its task requires.

Key takeaways

• GitHub Actions secrets are a lifecycle problem, not just a storage problem, because scale turns inherited scopes into hidden privilege paths.
• Rotation without auditability leaves incident responders blind, which is why static CI/CD credentials remain high-risk even when masked from logs.
• OIDC-backed workflow identity is the cleaner governance model because it replaces stored secrets with short-lived, runtime-validated access.

Key terms

• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• OpenID Connect For Workflows: OpenID Connect for workflows lets a running job present a short-lived identity token instead of storing a long-lived secret. In CI/CD, that shifts access from static credential possession to runtime claim validation, which is a better fit for ephemeral machine execution.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• Secrets Rotation: Secrets rotation is the practice of replacing credentials on a schedule or after an event so exposed values stop working quickly. In NHI programmes, rotation must be tied to ownership and automation, otherwise credentials remain valid long after teams believe the risk has been addressed.

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.

👉 The full Infisical article covers the workflow configuration, claim settings, and runtime credential flow in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.