GitHub Actions supply chain attacks expose secret governance gaps

At a glance

What this is: This is StepSecurity’s analysis of how TeamPCP’s Trivy compromise and the later KICS compromise exploited trusted GitHub Actions to steal credentials.

Why it matters: It matters because CI/CD workflows often carry production secrets and elevated tokens, so IAM, PAM, and NHI teams need controls that cover both build-time trust and runtime abuse.

By the numbers:

• In March 2026, attackers injected a credential stealer into 76 of 77 version tags of aquasecurity/trivy-action.

👉 Read StepSecurity's analysis of the Trivy and KICS GitHub Actions compromises

Context

GitHub Actions supply chain attacks are a governance problem as much as a software integrity problem. When a workflow action can be changed after teams have approved it, the trust boundary moves from code review to tag integrity, runner isolation, and secret handling, which is where many programmes are weakest. This article is about that control gap in CI/CD pipelines, where credentials are often available to jobs that were never meant to become security targets.

The identity angle is direct: GitHub Actions runners routinely handle service account tokens, cloud credentials, deployment keys, and other NHI secrets. Once those secrets are reachable from a compromised action, traditional IAM approval logic is too late unless runtime controls, immutable references, and inventory-based governance are already in place. That starting position is unfortunately common in modern build environments, not an outlier.

Key questions

Q: What breaks when GitHub Actions are referenced by tag instead of SHA?

A: The trust target becomes mutable. If an attacker can move the tag or compromise the referenced repository, the consuming workflow runs code that was never actually approved. That defeats review-based controls because the identity of the action can change after the decision to trust it.

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

A: Because workflows often run with access to repository tokens, cloud credentials, and runner state, a compromise can reveal more than code. When secrets remain valid after exposure, the workflow becomes a standing privilege path rather than a one-time event.

Q: How do security teams know whether a compromised action affected them?

A: They need an inventory of every repository, workflow, and run that referenced the affected action, plus whether each usage was pinned or mutable. Historical run data matters because compromise windows often span multiple days. Without central inventory, teams must grep repos manually and risk missing older workflows that still executed the malicious version.

Q: Who is accountable when a third-party action steals deployment credentials?

A: Accountability is shared across the repository owner, the platform team, and the application owner that approved the dependency. The practical question is whether the organisation pinned immutable versions, reviewed action provenance, and limited secret scope. Frameworks such as NIST SP 800-53 and OWASP NHI both support that shared control model.

Technical breakdown

How mutable Git tags turn trusted actions into supply chain entry points

GitHub Actions workflows often reference actions by version tag because tags are readable and convenient, but tags are mutable unless the repository enforces strong release controls. If an attacker gains tag or commit control, every workflow referencing that tag can silently execute different code on the next run. In the Trivy case, the malicious code was pushed into existing tags, which bypassed normal review expectations. The core technical weakness is not just repository compromise, but the assumption that a named version string is stable when it is not. This is why immutability matters in pipeline trust models.

Practical implication: replace mutable tags with pinned commit SHAs and block unapproved tag-based references in workflow policy.

Why runner memory access turns GitHub Actions into an NHI secret target

A compromised action does not need to wait for a developer to type a password. In a runner, secrets are already present in environment variables, process memory, or mounted contexts so jobs can deploy, test, or publish artifacts. The Trivy malware read /proc/pid/mem from the Runner.Worker process to extract marked secrets, which is a direct abuse of runtime access rather than a traditional login theft. This is why GitHub Actions environments behave like high-value identity zones: the identity is the workflow, the privilege is the job token or cloud secret, and the attack surface is the runner itself.

Practical implication: treat runner process access as privileged access and isolate jobs so secrets are not broadly readable in memory.

How defense in depth works across prevention, detection, and response

Supply chain compromise is difficult to stop with a single control because attackers can change tactics across the attack path. Network egress controls stop exfiltration, process monitoring catches suspicious memory scraping, immutable references block malicious tags, and inventory mapping tells you where the compromised action is used. The value of layered controls is that each one reduces a different failure mode, so the attacker must succeed multiple times to reach impact. In GitHub Actions, that means governance cannot live only in repository policy or only in runtime monitoring. The controls have to reinforce each other across the entire workflow lifecycle.

Practical implication: build layered CI/CD governance that combines pre-execution policy, runtime controls, and exposure inventory.

Threat narrative

Attacker objective: The attacker objective was to steal cloud and deployment credentials from GitHub Actions workflows and reuse them for downstream compromise.

1. Entry occurred when TeamPCP compromised a trusted GitHub Action and rewrote version tags so workflows pulled malicious code instead of the expected release.
2. Credential access followed when the malware read secrets from the Runner.Worker process memory and harvested environment variables exposed to the job.
3. Impact came when the stolen credentials were prepared for exfiltration to an attacker-controlled domain, turning build infrastructure into a secret theft channel.

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

Mutable action references create a hidden trust window: teams assume a tagged GitHub Action is stable, but the control boundary is actually the release mechanism behind the tag. When an attacker can rewrite tags, the pipeline inherits attacker code without a workflow file change. The governance failure is not just weak code review, but reliance on a reference type that can change after approval. Practitioners should treat tag pinning as a baseline control, not a hardening extra.

GitHub Actions runners function as non-human identity execution environments: the workflow identity, its secrets, and its runtime privileges form a machine identity estate that must be governed like any other privileged access domain. That means IAM and PAM teams need visibility into where tokens exist, how long they remain valid, and what the runner can read at execution time. The boundary between build automation and identity governance is now operational, not theoretical.

Runtime secret scraping is the specific failure mode this attack exposed: the attack did not rely on password guessing or interactive compromise, it abused the fact that secrets were present in process memory during execution. This is a named concept we should call secret exposure at runtime, not just secret sprawl. It shows why static repository review cannot substitute for runner isolation, memory protection, and egress control. Controls must address the moment secrets are live, not only where they are stored.

Defense in depth is the only rational control model for workflow compromise: supply chain attacks against actions can evade any single safeguard, so organizations need overlapping policy, monitoring, and response. That aligns with NIST CSF and MITRE ATT&CK thinking, where prevention, detection, and response each reduce different stages of adversary movement. Practitioners should re-evaluate whether their CI/CD governance assumes one control can carry the whole burden.

From our research:

• From our research: the average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Use 52 NHI Breaches Analysis to compare this attack pattern with other identity and secret exposure incidents.

What this signals

CI/CD governance is moving from repository hygiene to runtime assurance, because the meaningful control point is now the runner, not only the source tree. Teams that still rely on review alone will miss the window in which secrets are live and stealable.

Secret exposure at runtime: this is the governance gap where credentials exist in memory long enough to be scraped even when the source code looked clean. It connects directly to Top 10 NHI Issues and to the external control model in the OWASP Non-Human Identity Top 10.

Practitioners should expect more attacks that target the execution layer of developer tooling, especially where job tokens, cloud keys, and package signing secrets are automatically injected. That makes inventory, pinning, and egress control the baseline for any programme that treats software delivery as part of identity governance.

For practitioners

• Pin every GitHub Action to immutable commit SHAs Replace mutable version tags with full-length commit SHAs and block workflow merges that reference tags for sensitive pipelines. Add policy checks that reject action updates unless the SHA is reviewed and intentionally changed.
• Restrict secret exposure inside runners Limit which jobs can access deployment secrets, shorten token lifetime, and isolate high-risk workflows so secrets are not broadly available in environment variables or process memory.
• Apply egress allowlisting to CI/CD jobs Permit only approved outbound destinations from build runners and alert on first-seen domains, typosquat lookups, or unapproved exfiltration attempts from workflow execution.
• Inventory action usage across repositories Map every workflow that references third-party actions so you can identify exposure immediately when a compromise is announced, including mutable tags and historical run windows.

Key takeaways

• GitHub Actions compromises matter because they convert trusted automation into a live secret theft path.
• The Trivy and KICS incidents show that mutable tags, runner memory access, and weak egress controls combine into a repeatable attack pattern.
• Teams need immutable references, runtime containment, and complete workflow inventory if they want to reduce blast radius.

Key terms

• Mutable Git Tag: A mutable Git tag is a version label that can be moved to point at different commits after publication. In CI/CD pipelines, this creates a trust problem because a workflow may execute code that differs from what reviewers originally approved, especially when third-party actions are consumed by tag instead of immutable reference.
• Runner.Worker process: Runner.Worker is the GitHub Actions worker process that executes jobs and handles job-request data. Because it can contain environment values and secret-related data during a run, it becomes a sensitive runtime boundary that attackers may target if workflow code is compromised.
• Workflow Run Policy: A workflow run policy is a pre-execution governance control that evaluates a GitHub Actions run before code executes. It can block or cancel runs that violate security rules, such as use of compromised actions, mutable references, or disallowed workflow patterns, reducing the chance of secret exposure.
• Secret Exfiltration Path: Any route by which sensitive material can leave an environment after it has been read, including shell commands, web requests, diagrams, logs, or rendered outputs. In AI-assisted workflows, the exfiltration path can be created by the assistant itself if output controls are too permissive.

What's in the full article

StepSecurity's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step mapping of the ten security layers across the Trivy attack lifecycle and the KICS compromise
• Runner configuration detail for Harden Runner in block mode, audit mode, and lockdown mode
• Workflow Run Policies examples for known compromised actions and organization-wide cancellation
• Actions Inventory views that identify pinned versus mutable references across repositories

👉 The full StepSecurity article covers the ten-layer defense model, attack timeline mapping, and incident response workflow.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners translate governance into controls that hold up during real attacks.