TL;DR: Mutable tags, runner-level secret access, and weak runtime monitoring let attackers turn trusted workflows into credential-stealing infrastructure, according to StepSecurity’s analysis of the Trivy and KICS GitHub Actions compromises. Defense in depth matters because no single control can stop code injection, memory scraping, and exfiltration once a pipeline is compromised.
NHIMG editorial — based on content published by StepSecurity: Product 10 Layers Deep: How StepSecurity Stops TeamPCP's Trivy Supply Chain Attack on GitHub Actions
By the numbers:
- In March 2026, attackers injected a credential stealer into 76 of 77 version tags of aquasecurity/trivy-action.
Questions worth separating out
Q: What breaks when GitHub Actions are referenced by tag instead of SHA?
A: The trust target becomes mutable.
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.
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.
Practitioner guidance
- 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.
- 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.
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
👉 Read StepSecurity's analysis of the Trivy and KICS GitHub Actions compromises →
GitHub Actions supply chain attacks: are your controls keeping up?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: GitHub Actions supply chain attacks expose secret governance gaps