Notifications
Clear all
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.
NHIMG editorial — based on content published by Orca Security: GitHub Actions security risks and workflow abuse
By the numbers:
- GitHub Actions is now the most widely used CI/CD platform at 51% adoption.
- GitHub Actions ranks as the second most-used CI/CD tool with a 33% adoption rate.
Questions worth separating out
Q: How should security teams reduce workflow privilege in GitHub Actions?
A: Start from a deny-by-default permission model, then grant only the exact repository and deployment rights each job needs.
Q: Why do GitHub Actions workflows create secrets management risk?
A: Workflows often need credentials to reach APIs, cloud platforms, and internal services, which makes them high-value identity targets.
Q: What breaks when untrusted pull request content is executed in a workflow?
A: The workflow stops being a controlled automation step and becomes an attacker-controlled command channel.
Practitioner guidance
- Reset workflow permissions to zero by default Start each repository with permissions: {} and grant only the minimum access needed per job.
- Remove secrets from workflow code paths Store credentials in managed secret stores, inject them only at runtime, and audit logs and debug output for accidental disclosure.
- Separate untrusted triggers from privileged execution Do not run attacker-controlled pull request content in jobs that can access deployment tokens or repository write permissions.
What's in the full article
Orca Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Code examples for hardcoded secrets, permission scoping, and workflow injection patterns that implementation teams can adapt.
- The article’s breakdown of trigger types, job anatomy, and where each control failure typically appears in the pipeline.
- Expanded examples of artifact poisoning, self-hosted runner compromise, and why apparently minor workflow choices change blast radius.
👉 Read Orca Security's analysis of GitHub Actions security risks and workflow abuse →
GitHub Actions workflow risk: are your CI/CD controls keeping up?
Explore further
25/06/2026 2:36 am
GitHub Actions should be treated as a non-human identity control plane, not a build convenience. The article shows workflows inheriting secrets, repository authority, and deployment reach, which places CI/CD squarely inside identity governance. Once the workflow can authenticate, modify, and trigger downstream systems, IAM teams need to govern it as an active identity with scoped privilege and lifecycle boundaries.
A few things that frame the scale:
- From our research: 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.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
A question worth separating out:
Q: How should teams handle third-party GitHub Actions in production pipelines?
A: Treat each third-party action as delegated trust and verify it before use. Pin it to immutable references, review its dependencies, and restrict what secrets or deployment permissions it can reach. If an action can influence releases, credentials, or self-hosted runners, it belongs in the same risk tier as any external machine identity.
👉 Read our full editorial: GitHub Actions security risks expose secrets and privileged workflows
