Why do GitHub Actions workflows increase the risk of secret exposure?

Why This Matters for Security Teams

GitHub Actions is attractive because it turns code changes into automated execution, but that same convenience expands the blast radius of any secret available to the workflow. A runner can receive repository tokens, cloud credentials, deployment keys, and cached state, then pass them to third-party actions or injected steps. Once a secret is exposed, the workflow can become a standing privilege path rather than a one-time incident.

This risk is not theoretical. The Guide to the Secret Sprawl Challenge highlights how widely secrets now leak across engineering workflows, and the OWASP Non-Human Identity Top 10 treats exposed or overprivileged machine credentials as a primary control failure, not an edge case. Security teams often focus on source code review while underestimating that the workflow runner itself is an execution environment with access to identities, tokens, and ephemeral trust decisions.

NHIMG research shows the scale of the issue: 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities by Oasis Security & ESG. In practice, many security teams encounter workflow secret exposure only after a token has already been reused outside the pipeline, rather than through intentional review of runner trust boundaries.

How It Works in Practice

The core problem is that GitHub Actions does not just run code; it orchestrates trust across multiple identities and execution contexts. A workflow may read secrets from repository settings, environment secrets, OIDC federation, or inherited permissions from the default GITHUB_TOKEN. If an attacker can alter a workflow file, compromise a dependency, or influence a reusable action, they can often exfiltrate credentials directly from the runner environment or use them indirectly to access cloud resources.

That is why static, long-lived secrets are especially dangerous in CI/CD. Best practice is evolving toward short-lived credentials, tight scoping, and request-time authorization rather than broad pre-issued access. For example, workload identity and federated tokens reduce reliance on stored secrets by proving what the workflow is at runtime, not just handing it a reusable password. The OWASP guidance and the NIST Cybersecurity Framework 2.0 both align with reducing standing access and strengthening verification at the point of use.

• Use least privilege for the default token and disable write permissions unless a job truly needs them.
• Prefer short-lived OIDC-based federation to stored cloud keys wherever the platform supports it.
• Limit secret availability to the smallest job or environment that requires it.
• Pin and review third-party actions, since action supply chain compromise can turn the runner into a credential harvesting point.
• Rotate or revoke secrets quickly after use, especially for deployment and infrastructure access.

NHIMG case studies such as the Reviewdog GitHub Action supply chain attack and the CI/CD pipeline exploitation case study show how quickly one trusted workflow can become a credential exfiltration path. These controls tend to break down when reusable workflows, self-hosted runners, and broad environment inheritance are combined, because privilege becomes distributed across several layers that are hard to review consistently.

Common Variations and Edge Cases

Tighter workflow controls often increase build friction and maintenance overhead, requiring organisations to balance delivery speed against credential exposure risk. That tradeoff is real, especially in fast-moving repositories where developers rely on temporary exceptions to keep pipelines green.

Public repositories, self-hosted runners, and reusable workflows create different failure modes. Public repos raise the risk of untrusted pull requests probing workflow behaviour, while self-hosted runners can retain disk state, environment variables, or tool caches longer than expected. Reusable workflows help standardise security, but they also concentrate trust: one poorly designed shared workflow can spread insecure secret handling across many repositories. Current guidance suggests treating workflow secrets as high-risk NHI assets, not as ordinary application configuration.

There is no universal standard for GitHub Actions secret governance yet, but the direction is clear: runtime authorization, ephemeral credentials, and explicit trust boundaries outperform static secret storage. Teams should also assume that secret scanning alone is insufficient, because detection after exposure does not prevent misuse. The safest path is to minimise standing credentials and make each workflow request narrowly scoped access only when it is needed.

For broader machine-identity controls and governance patterns, the Ultimate Guide to NHIs — Why NHI Security Matters Now is useful context, especially when organisations are trying to standardise identity controls across CI/CD and cloud automation.

Related resources from NHI Mgmt Group

• Why do AI-assisted security workflows increase identity risk in cloud environments?
• When do AI-generated code and assistants increase secret exposure risk?
• How should security teams reduce risk from compromised GitHub Actions workflows?
• Why do local AI platforms increase NHI secret exposure risk?