GitHub Actions supply chain attacks expose secret governance gaps

At a glance

What this is: StepSecurity examines how the Trivy and KICS GitHub Actions compromises turned trusted automation into secret-stealing infrastructure by exploiting mutable tags, runner memory access, and limited runtime monitoring.

Why it matters: It matters to IAM and NHI practitioners because CI/CD runners, workflow tokens, and third-party actions behave like privileged identities, so governance must cover issuance, pinning, detection, and rapid revocation.

By the numbers:

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

Context

GitHub Actions pipelines are not just build automation, they are privileged execution environments that often hold production credentials, cloud tokens, and deployment keys. When a trusted action is compromised, the attacker inherits that trust boundary and can target secrets during runtime rather than at the edge of the enterprise.

The governance gap is that many teams still treat workflow references, runner trust, and secret exposure as separate problems. In practice they are one control plane, and the identity angle is real because runners, tokens, and third-party actions function as machine identities with delegated access.

The Trivy and KICS compromises are typical of modern supply-chain abuse, not one-off anomalies. They show what happens when mutable references and weak runtime visibility meet highly privileged automation.

Key questions

Q: What breaks when GitHub Actions workflows use mutable dependencies and overprivileged tokens?

A: The reviewed workflow is no longer the executed workflow. Mutable actions can change after approval, and overprivileged tokens turn that change into repository control or secret exposure. The result is a trust gap where the pipeline looks governed but actually behaves like an unbounded access path.

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 you know whether a GitHub Actions workflow is actually secure?

A: A workflow is only as secure as its reference integrity, secret scope, and runtime monitoring. If it uses mutable tags, grants broad job permissions, or has no visibility into outbound network traffic and process behaviour, the control set is incomplete. Security evidence should include pinned references, limited token scope, and alerts for suspicious runner activity.

Q: When should teams cancel or quarantine a GitHub Actions run?

A: Teams should cancel a run when the workflow resolves to a known compromised action, a suspicious commit that is not on an expected branch, or an execution path that violates policy before any step completes. The goal is to stop secret-bearing execution before the job can establish network connections or read process memory.

Technical breakdown

How mutable tags turn trusted actions into execution risk

GitHub Action tags are pointers, not immutable code references. If an attacker can move a tag, every workflow that consumes that tag can be redirected to malicious content without changing the repository path in the workflow file. That is why tag trust is a governance issue, not just a versioning preference. In supply-chain attacks, the attacker does not need to compromise the consuming repository first; they only need to control the reference target that the workflow resolves at runtime. Immutable commit SHAs break that path because the reference binds to content, not to a movable label.

Practical implication: pin third-party actions to immutable commit SHAs wherever workflow risk is material.

Why runner memory access changes the secret exposure model

GitHub Actions runners often receive secrets into environment variables or process memory during execution. Once a compromised action is running inside that context, it can search process memory, scrape variables, and reuse any credential that was available to the job. This is why the identity problem is broader than token theft alone: the workflow runtime becomes a temporary privileged identity boundary with secrets attached. If the job can access the Runner.Worker process memory, then any secret loaded for that session can be treated as exposed unless the runtime is actively constrained.

Practical implication: assume in-memory secret exposure is possible and pair secret delivery with runtime containment.

Why pre-execution gating matters more than post-run review

Post-run logs and manual review tell you what happened after code has already executed, which is too late for high-value automation. Pre-execution policy checks change the control point by evaluating the workflow before steps start, so a known-compromised action never gets a chance to load secrets or contact an external domain. That shift matters because supply-chain incidents move quickly across repositories and tags, while human review is slow. In security terms, the control needs to happen at resolution time, not after job completion.

Practical implication: block known-compromised actions before execution and use inventory to see where they are referenced.

Threat narrative

Attacker objective: The attacker objective was to steal CI/CD secrets, cloud tokens, and deployment credentials from trusted GitHub Actions executions.

1. Entry occurred through compromise of a popular GitHub Action, allowing the attacker to weaponize mutable version tags in trusted workflows.
2. Credential harvest followed when the malicious action read secrets from the Runner.Worker process memory and collected environment variables.
3. Exfiltration completed when the stolen data was sent to an attacker-controlled domain from inside the workflow runtime.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mutable action references create secret governance debt: when workflows rely on tags instead of immutable references, the organisation has delegated trust to a label that can move. That makes the control failure structural, not accidental, because the workflow can run unreviewed code under a legitimate repository path. For identity teams, this is a machine-identity governance problem as much as a software-supply-chain issue. Practitioners should treat tag pinning as a baseline control, not an advanced hardening step.

Runner memory is now part of the secret perimeter: once secrets are loaded into a CI/CD runner, the attack surface extends into process memory and runtime telemetry. This is where the compromise becomes an identity abuse problem, because the workflow runtime is effectively a privileged non-human identity with transient authority. NIST-CSF and OWASP-NHI both point toward controlling access permissions and secret handling at the issuance and execution boundary. Practitioners need runtime controls that assume secrets may be observed during execution.

Pre-execution policy beats post-incident forensics: the category is moving toward controls that stop compromised actions before any step runs, because post-run detection only helps after secrets may already be gone. That shift validates inventory-led governance, known-compromised action lists, and immutable references as core controls rather than optional maturity upgrades. The practical conclusion is straightforward: the earlier the control point, the smaller the blast radius.

Secret governance in CI/CD is becoming a supply-chain discipline: the Trivy and KICS incidents show that third-party actions, workflow policies, and runner telemetry now sit in the same governance chain. That means organisations cannot separate secret management from pipeline trust or incident response. Teams that still manage these as isolated domains will keep missing the real control gap, which is the handoff between trusted code resolution and secret-bearing execution.

Actions inventory is the missing response layer: when compromise hits, responders need to know where an action is referenced, whether it is pinned, and which runs executed during the compromise window. That is a governance and evidence problem, not just a detection problem. Practitioners should expect their incident process to depend on asset-level visibility into workflow references and usage.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Mutable workflow references are now a governance liability: the Trivy and KICS cases show that supply-chain compromise can begin with a reference control, not a vulnerability in the consuming repository. When third-party actions are allowed to drift, defenders lose the ability to reason about which code actually ran. Organisations should treat reference immutability as part of identity governance for pipelines, not as a cosmetic DevOps preference.

CI/CD runners behave like privileged non-human identities: they carry secrets, tokens, and deployment authority that should be scoped, monitored, and revoked with the same discipline applied to other machine identities. That makes GitHub Actions governance relevant to NHI programmes even when the primary issue is supply chain security. The control conversation has to move from trust in the action source to control over the runtime boundary.

Secret governance in pipelines now depends on inventory, not memory: teams cannot respond quickly if they do not know where an action is used or whether it is pinned. This is where actions inventory becomes operationally critical, because it turns a broad compromise into a bounded exposure set. In practice, the response question is not whether a workflow might be affected, but which repositories and runs are actually exposed.

For practitioners

• Pin all third-party GitHub Actions to immutable SHAs Replace mutable tags with full commit references for any action that can reach secrets, deploy artifacts, or touch production paths.
• Restrict secrets exposure in workflow jobs Review which jobs receive environment variables, cloud tokens, and deployment keys, then remove unnecessary secrets from jobs that do not need them.
• Add runtime controls for runner containment Use egress allowlisting and process monitoring so a compromised action cannot freely call out or scrape process memory during execution.
• Maintain an actions inventory with pinning status Map every repository that references third-party actions, identify mutable references, and keep a list of runs that executed during a compromise window.
• Automate compromise response for known bad actions Create pre-execution rules that cancel runs referencing known compromised actions and route those events into your incident workflow immediately.

Key takeaways

• GitHub Actions compromise becomes a secret governance problem when mutable references and privileged runners let attackers execute trusted workflows as credential-stealing infrastructure.
• The Trivy incident shows how quickly supply-chain abuse can scale when a malicious action reaches in-memory secrets and outbound network paths inside the runner.
• Pinned references, runtime containment, and inventory-led response are the controls that change the outcome when a workflow provider or tag is compromised.

Key terms

• GitHub Action Supply Chain Compromise: A compromise in which a third-party GitHub Action or its repository is altered so downstream workflows execute attacker-controlled code. The risk comes from the trust relationship between the workflow and the action reference, especially when teams rely on mutable tags rather than immutable commit identifiers.
• Mutable Tag: A mutable tag is a repository reference that can be moved to a different commit after it has been published. In software supply chains, mutable tags are risky because they let an attacker or compromised maintainer change what future builds and workflows execute without changing the calling configuration.
• Runner Memory Scraping: The technique of reading process memory on a build or CI runner to extract credentials, tokens, or plaintext secrets that were never written to disk. It is effective because many pipelines inject sensitive values into runtime memory for legitimate work, creating a high-value target inside the process boundary.
• Log Inventory: A log inventory is a structured catalog of log sources, their owners, ingestion methods, formats, and supporting documentation. It tells a team what data exists, where it comes from, and how it is parsed. For AI workflows, it provides the context needed to avoid guessing about fields or coverage.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect pipeline trust, credential scope, and identity lifecycle control across modern delivery environments.