GitHub Actions security gaps that keep enabling supply chain attacks

At a glance

What this is: This is a GitHub Actions security checklist that maps common workflow misconfigurations to the attack paths they create, with a focus on secrets exposure, script injection, and supply chain abuse.

Why it matters: It matters because CI/CD pipelines often hold publish rights, cloud credentials, and other NHI secrets, so weak workflow governance can convert a single PR or compromised action into broad downstream impact.

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 Aikido's GitHub Actions security checklist for the full workflow hardening detail

Context

GitHub Actions security is fundamentally a governance problem about where trust is granted inside automation. The primary risk is that convenience features such as fork-triggered workflows, mutable references, and broad token permissions can turn untrusted input into code execution or credential exposure.

For identity and access teams, the article sits at the intersection of CI/CD security and non-human identity governance. Workflow tokens, cloud federation, publish credentials, and bot-driven automation all behave like NHI assets that need explicit scope, lifecycle control, and revocation discipline, not just defensive scanning.

Key questions

Q: What breaks when GitHub Actions workflows run untrusted pull requests with write access?

A: The workflow boundary breaks because attacker-controlled input can execute in a privileged context. That lets an untrusted contribution inherit repository rights, secret access, or release permissions that should never be available during validation. The result is token leakage, unauthorized repository actions, or both, especially when pull_request_target is combined with broad permissions.

Q: Why do GitHub Actions secrets need shorter lifetimes than traditional CI credentials?

A: Because CI jobs are ephemeral and attacker access, if gained, is usually immediate. Long-lived credentials survive beyond the job and can be reused across environments or later compromises. Short-lived OIDC-based tokens reduce the reuse window and limit the value of any token that leaks from a runner or action.

Q: How do security teams know if a workflow is still too permissive?

A: Look for secret access on untrusted events, action references that move without review, cache writes from forked runs, and any job that can publish or deploy without a protected branch or environment gate. If a workflow can both ingest untrusted input and spend real privilege, it is still over-permissive.

Q: What should teams do when AI agents are embedded in GitHub Actions workflows?

A: Keep the agent read-only unless there is a tightly justified exception, and never feed raw issue text or PR descriptions into a prompt that can drive privileged tool use. Treat the agent as a non-human identity with narrow scope, because prompt injection becomes a control failure when the agent can also access secrets or write back to the repository.

Technical breakdown

Why GitHub Actions trigger design creates privilege gaps

GitHub Actions supports triggers such as pull_request_target and workflow_run that execute in privileged repository contexts. The security boundary matters because these triggers can load secrets or grant write permissions even when the originating code came from a fork or other untrusted source. If the workflow later checks out attacker-controlled content or consumes upstream artifacts without validating the event path, the privileged runner becomes an execution bridge rather than a control point. This is why the article repeatedly focuses on trigger selection before any hardening detail. The issue is not automation itself, but the mismatch between event trust and runtime privilege.

Practical implication: Map every privileged trigger to a specific trust boundary and remove any path that allows untrusted content to reach secret-bearing jobs.

How untrusted input becomes script injection in workflows

Branch names, pull request titles, commit messages, and issue bodies are attacker-controlled inputs when they originate outside the maintainer set. In shell steps, directly interpolating those values can cause the shell to parse them as syntax rather than data, which is the same class of problem as command injection in web applications. Assigning values to environment variables first forces runtime string handling instead of parse-time evaluation. The article also extends this to AI agent prompts inside workflows, where raw issue text or PR descriptions can steer an agent into writing files, exposing secrets, or invoking tools with elevated permissions.

Practical implication: Treat every github.* value and every AI prompt source as hostile input unless it has been normalised, isolated, and permission-limited.

Why secrets handling depends on scope and short-lived identity

A secret is only safe if its exposure window, scope, and downstream use are constrained. GitHub Actions workflows often fail when the same secret is available across many steps, jobs, or repo-wide contexts, because any compromised action in that path can read it. OIDC changes the model by replacing long-lived static credentials with short-lived cloud tokens bound to the job. That does not remove identity risk, but it narrows the blast radius and makes stolen material less reusable. For CI/CD, the right question is not whether secrets exist, but whether they are still standing when an attacker reaches them.

Practical implication: Prefer OIDC and step-level scoping so publish rights and cloud access expire with the job that requested them.

Threat narrative

Attacker objective: The attacker wants to convert a single workflow weakness into durable credential theft and downstream software supply chain compromise.

1. Entry begins when an attacker submits a pull request, issue comment, or crafted branch name that reaches a privileged GitHub Actions trigger.
2. Escalation occurs when the workflow exposes secrets, executes injected shell content, or consumes attacker-controlled artifacts in a write-capable context.
3. Impact follows when stolen tokens, publish credentials, or cloud access are reused to push malicious packages, move through accounts, or poison downstream builds.

NHI Mgmt Group analysis

GitHub Actions has become a non-human identity governance problem, not just a CI hardening problem. The workflows, tokens, publish credentials, and cloud federation paths described here all behave like machine identities with varying scope and lifecycle. When those identities are granted broadly or triggered from untrusted events, the platform becomes an access broker for attackers. Practitioners should treat workflow design as identity design, not just pipeline hygiene.

Standing workflow privilege is the core failure mode this checklist exposes. The repeated pattern is that a trigger, token, or trusted publishing rule stays valid longer and more broadly than the task it was meant to support. That creates an exposure window that attackers can reach through forks, comments, or orphaned commits. The practical conclusion is that privilege must be narrow enough to survive hostile inputs, not merely correct in the happy path.

Mutable references and untrusted inputs create a trust boundary the build system cannot self-enforce. Pinning actions to commit SHAs, avoiding interpolation, and constraining cache writes are not cosmetic controls. They prevent the pipeline from treating remote content as if it were local code. For identity programmes, this is the same lesson as least privilege in PAM and NHI governance. The environment must assume the next input is hostile.

AI agents inside workflows extend the same attack surface into agentic AI governance. If an agent can read issue text or PR descriptions and also call tools or access secrets, prompt injection becomes a privileged execution path rather than a harmless text manipulation. That means agent oversight, tool scoping, and prompt sanitation belong in the same control set as token management. Practitioners should govern workflow agents as identities with constrained authority, not as productivity helpers.

Named concept: workflow trust boundary collapse. The article shows how a workflow can cross from safe automation into attacker-controlled execution when untrusted events, secret access, and mutable dependencies are combined. This failure mode helps explain why controls must bind privilege to event provenance, branch protection, and short-lived identity. Teams should use it as a shorthand for reviewing any pipeline that can both read input and spend trust.

What this signals

Workflow trust boundary collapse: CI/CD governance now has the same structure as identity governance because workflow tokens, environment secrets, and trusted publishing rules function like short-lived or standing machine identities. Once those identities can be reached from untrusted triggers, the pipeline stops being a defensive layer and becomes an attack surface. Teams should review every job that can both ingest external content and spend privilege.

The practical shift is toward job-scoped authority, branch-scoped publishing, and strict separation between untrusted reads and privileged writes. That matters because GitHub Actions incidents rarely start with sophisticated exploitation. They start with a control that assumed the event source was trustworthy. A workflow inventory that maps secrets, triggers, and outputs is now a governance requirement, not an operational nice-to-have.

For identity programmes, this is also a reminder that NHI controls extend into software delivery. OIDC, environment scoping, and secret rotation need to be evaluated alongside action pinning and cache policy so that the same machine identity is not reused across unrelated trust zones. When build automation can publish software, it is part of the access model, not separate from it.

For practitioners

• Remove privileged execution from untrusted triggers Disable pull_request_target and similar high-trust triggers in public repositories unless the workflow never checks out fork code and never accesses secrets. If a downstream job only needs to deploy on maintainer changes, trigger it directly from push on the protected branch instead of chaining privilege through workflow_run.
• Pin every third-party action and dependency Reference actions by full commit SHA, not tags or moving versions, and lock package installs to exact versions. This prevents a compromised upstream release from silently changing the code your workflow executes on the next run.
• Move cloud and publish credentials to short-lived identity Replace long-lived static secrets with OIDC where AWS, Azure, or GCP support it, and scope access to the specific job that needs it. Use GitHub Environments and step-level secret exposure so a compromised action cannot reuse a repo-wide credential.
• Sanitise every untrusted workflow input before execution Assign branch names, PR titles, commit messages, and issue bodies to environment variables before shell use, and keep raw values out of run steps and AI prompts. The same rule should apply to any agent that can read repository text and invoke tools.
• Separate cache writes from untrusted runs Use a push-triggered workflow to save cache content from the default branch, then let untrusted workflows only restore it. Never allow fork-driven runs to write cache entries derived from PR code, because that reintroduces poisoning through the restore path.

Key takeaways

• GitHub Actions becomes dangerous when trusted triggers, secrets, and mutable content are allowed to meet in the same workflow path.
• The evidence base behind CI/CD compromise is now large enough to treat secret sprawl and workflow misconfiguration as recurring governance failures, not edge cases.
• The strongest controls are narrow trigger design, short-lived identity, immutable references, and strict separation between untrusted input and privileged execution.

Key terms

• Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.
• Short-Lived Identity: A short-lived identity is a credential or identity assertion that exists only for a narrow task window and is automatically revoked or expires afterward. In NHI governance, it reduces standing privilege and limits the time available for misuse, while improving control over distributed access patterns.
• Secret exposure window: A secret exposure window is the period between when a credential becomes visible to an attacker and when it is detected, revoked, or rotated. In CI/CD environments that window can be extremely short, which is why detection speed and identity-linked revocation matter as much as storage hygiene.
• Prompt Injection in Automation: A manipulation technique where attacker-controlled text changes the behaviour of an AI system embedded in a workflow. In CI/CD, issue text or pull request content can become instructions if the agent is allowed to act on it with repository or cloud privileges.

What's in the full article

Aikido's full guide covers the operational detail this post intentionally leaves for the source:

• Exact workflow patterns to avoid in public repositories, including safer event routing for pull requests and downstream jobs
• Concrete examples of shell interpolation mistakes and how to rewrite them safely in real workflow syntax
• Step-by-step secret scoping approaches using GitHub Environments, job-level permissions, and OIDC federation
• Tooling references for detecting unsafe triggers, mutable references, and secret exposure across a repo estate

👉 Aikido's full guide covers the trigger patterns, secret scoping choices, and workflow examples in depth

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives security and identity practitioners a common control language for machine identities that span CI/CD, cloud, and automation.