Topic starter
23/06/2026 9:20 pm
TL;DR: GitHub Actions now reaches 51% adoption in CNCF’s 2024 survey and 33% in JetBrains’ 2024 developer report, but Orca Security argues that teams still underestimate how secrets exposure, overbroad tokens, mutable actions, and pull request injection turn automation into an attack surface. The governance gap is not the workflow engine itself, but the assumption that CI/CD automation can be trusted like ordinary application code.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Part 1: Attackers Love Your GitHub Actions Too”.
By the numbers:
- GitHub Actions ranks as the second most-used CI/CD tool with a 33% adoption rate, according to Orca Security.
- GitHub Actions is now the most widely used CI/CD platform at 51% adoption, according to Orca Security.
Key questions
Q: What breaks when GitHub Actions workflows are allowed to access secrets without approval?
A: When workflow secret access is not gated, an attacker can turn the CI runner into the exfiltration tool.
Q: Why do overprivileged CI/CD components create such high supply chain risk?
A: Overprivileged pipeline components turn a routine build system into a high-value attack path.
Q: What are the signs that a GitHub Actions workflow_run setup is unsafe?
A: The clearest warning signs are privileged jobs that check out untrusted repository code, parse artifact contents directly into shell commands, or rely on interpolated workflow inputs.
Practitioner guidance
- Restrict workflow permissions by default Start each repository with explicit minimal permissions and grant only the scopes a job truly needs.
- Pin third-party actions to immutable commits Replace tag-based references such as version branches with commit hashes so action code cannot be silently repointed after approval.
- Separate untrusted pull request code from privileged jobs Keep contributor-controlled code away from workflows that have secrets, release permissions, or deployment access.
Bottom line: GitHub Actions becomes risky when teams treat workflow execution as ordinary code rather than as a privileged identity path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 2:36 am
GitHub Actions is best understood as a non-human identity estate, not just a build tool. Each workflow identity, token, action reference, and runner permission creates a governed access path. When teams treat that path like ordinary application code, they miss the fact that CI/CD is executing with production-relevant authority. The practitioner conclusion is straightforward: workflow access must be governed as identity, not merely reviewed as code.
A few things that frame the scale:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
Q: How should teams compare untrusted PR workflows and privileged release workflows?
A: Untrusted pull request jobs should validate code and produce non-sensitive outputs, while privileged release jobs should operate only on trusted artefacts and approved inputs. When the same workflow both ingests contributor code and has secrets or deployment access, the separation of duties has already broken down.
👉 Read our full editorial: GitHub Actions security risks expose secrets and privileged workflows