Why do GitHub Actions workflows create supply chain risk for CI/CD credentials?

Why This Matters for Security Teams

GitHub Actions workflows are not just build automation. They are execution paths that often carry secrets with release, signing, deployment, and repository administration privileges. That makes them a supply chain control plane, not a convenience layer. The risk is compounded because workflow logic is code, so changes to triggers, actions, or permissions can turn ordinary CI/CD into a credential exfiltration path. NHI governance becomes critical when the workflow identity itself can reach downstream systems.

Industry guidance increasingly treats this as a non-human identity problem. The OWASP Non-Human Identity Top 10 and NIST identity controls both emphasize that machine credentials need explicit lifecycle, scoping, and monitoring. NHIMG’s GitHub Action tj-actions Supply Chain Attack shows how quickly CI/CD secrets can become an enterprise-wide exposure when workflow trust is broken.

In practice, many security teams discover workflow credential abuse only after a malicious action version or compromised maintainer account has already propagated through multiple repositories.

How It Works in Practice

Most GitHub Actions risk comes from the gap between what a workflow can do and what it should be allowed to do. A workflow may have access to repository tokens, cloud credentials, package registry tokens, or signing keys. If an attacker can modify the workflow, swap a third-party action, poison a dependency, or influence the event that triggers execution, they may capture secrets at runtime or use the workflow’s identity to mint new access.

That is why current best practice is to reduce static credential exposure and move toward short-lived, purpose-scoped access. For CI/CD, that usually means GitHub OIDC federation into cloud or SaaS targets, branch and environment protections, least-privilege NIST SP 800-53 Rev. 5 Security and Privacy Controls, and careful review of third-party actions. The operational goal is to ensure the workflow proves what it is, what repo it came from, and what job context it is executing under before any downstream privilege is issued.

• Use ephemeral, per-run credentials instead of long-lived secrets in repository settings.
• Restrict token permissions to the minimum required for each job.
• Pin actions to verified commit SHAs, not floating tags.
• Segregate deploy, sign, and publish steps into protected environments.
• Monitor for unusual secret access, outbound calls, and release activity.

NHIMG’s CI/CD pipeline exploitation case study and the Ultimate Guide to NHIs - Static vs Dynamic Secrets both reinforce the same point: static CI/CD credentials create a reusable blast radius, while dynamic credentials narrow the window for abuse.

These controls tend to break down in monorepos with many inherited workflows because permission boundaries become difficult to verify at scale.

Common Variations and Edge Cases

Tighter workflow control often increases release friction, requiring organisations to balance developer velocity against credential containment. That tradeoff is real, especially where teams rely on reusable workflows, matrix builds, or external actions that must touch multiple environments.

One common edge case is the trusted internal workflow that becomes untrusted after a dependency or action update. Another is pull request workflows that expose read access to secrets through logs, caches, artifacts, or overly broad environment variables. Current guidance suggests treating forks, scheduled jobs, and self-hosted runners as separate trust zones, but there is no universal standard for this yet. The right answer depends on how much code an external contributor can influence and whether the runner can persist state between jobs.

Security teams should also assume that package publishing and artifact signing are especially sensitive. Those steps are often more powerful than the build itself because they let a compromised workflow shape downstream trust. NHIMG’s Reviewdog GitHub Action supply chain attack and Shai Hulud npm malware campaign are reminders that CI/CD compromise rarely stays inside one repository.

For governance maturity, NIST Cybersecurity Framework 2.0 is useful for mapping workflow hardening to risk management outcomes, while the OWASP guidance helps teams prioritise credential containment over convenience.

Related resources from NHI Mgmt Group

• Why do build tools and mirrors create identity risk as well as supply-chain risk?
• Why do package metadata parsers create supply-chain risk?
• Why do trusted dependencies create such a large supply chain risk for credentialed applications?
• Why do banking SDKs create such high-value supply-chain risk?