Notifications
Clear all
Topic starter
11/06/2026 11:05 pm
TL;DR: GitHub Actions attacks such as tj-actions, command injection in runner commands, and self-hosted runner abuse show how mutable dependencies, overprivileged tokens, and untrusted input can turn CI/CD into a secret-exposure path, according to Orca Security. The governance failure is not automation itself, but treating pipeline identities as if they were stable, reviewable, and low-risk.
NHIMG editorial — based on content published by Orca Security: GitHub Actions supply chain attacks and hardening techniques
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should teams secure GitHub Actions against supply chain compromise?
A: Teams should pin reusable actions to immutable commit SHAs, restrict token scope, and review every dependency that can execute inside a workflow.
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: What breaks when self-hosted runners are reused across jobs?
A: Reused runners can preserve tokens, local files, and hidden state between executions, which gives an attacker a place to persist.
Practitioner guidance
- Pin every reusable action to an immutable commit SHA Replace version tags and floating references with commit-level pins in all GitHub Actions workflows.
- Set repository tokens to read-only by default Grant write permission only to jobs that truly need it, and scope secrets to the smallest environment possible.
- Treat all repository input as untrusted data Handle pull request titles, issue text, and branch names as attacker-controlled content.
What's in the full article
Orca Security's full blog post covers the operational detail this post intentionally leaves for the source:
- A step-by-step breakdown of the tj-actions compromise path across injection, dependency tampering, and secrets exposure.
- Concrete hardening examples for GitHub Actions workflows, including pinning patterns, runner isolation, and permission settings.
- Specific tool recommendations for scanning and policy enforcement in CI/CD environments.
- Practical examples of how malicious workflow output can be turned into command execution.
👉 Read Orca Security's analysis of GitHub Actions supply chain attacks and hardening →
GitHub Actions supply chain attacks: what IAM teams missed?
Explore further
12/06/2026 7:36 am
CI/CD identity is production identity, not build convenience. GitHub Actions workflows carry secrets, token scope, and downstream authority, so they sit inside the identity control plane whether teams acknowledge it or not. When attackers compromise an action or inject into a runner, they are not just breaking software integrity, they are abusing an identity-bearing execution context. Practitioners should treat pipeline access as governed privilege, not as disposable automation.
A few things that frame the scale:
- 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, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to The State of Secrets Sprawl 2026.
A question worth separating out:
Q: Who is accountable when a workflow secret is exposed through a GitHub Action?
A: Accountability sits with the team that owns the workflow, the secrets, and the runner environment, because pipeline identities are part of the access model. Security, platform, and application teams should share ownership of approval boundaries, token scope, and revocation.
👉 Read our full editorial: GitHub Actions supply chain attacks expose NHI governance gaps
