Sources

This is one of the most prevalent and dangerous supply chain risks in GitHub Actions. Despite causing nightmare scenarios for tens of thousands of users this year, most developers still do not pin their actions properly. According to Wiz, only 3.9% of repositories pin 100% of their third-party Actions to an immutable commit SHA hash.

You can find all sorts of stuff in there- they're been so neglectful of the self hosted actions that it's embarrassing they're trying to charge for it. They don't release containers that match the runners on the public at all. They don't handle proper rootless docker-in-docker. All issues that have come up repeatedly. If they want to charge for things fine, but actually provide a service that doesn't require your users doing 90% of the work. ... Aside from the pricing change, GH Actions is not a "premium service" that is even worth paying for. The "control plane" suffers from multiple issues (see recent problems about broker / backend problems not relaying the messages) and the GH Actions ecosystem is broken in so many ways (e.g: safe_sleep). … #### ikemo3 Dec 18, 2025 ... I'm an individual developer on the Pro plan, but the included minutes aren't sufficient for my needs, so I separately contract with Ubicloud. Ubicloud is 1/10th the price of GitHub Actions (before this change), but if this additional charge is applied, the total cost becomes 3.5x higher. (In other words, I'd be paying GitHub 2.5x more than Ubicloud!) … #### vwnj84 Dec 19, 2025 ... It was really terrible from an Enterprise standpoint, because budgets are already set for different departments and development teams. They were told that all they needed to pay for was their infrastructure, not the scheduler, since that's a huge part of what they're already paying for with their per-person Enterprise license. Then this was announced, and suddenly here at the end of the year, we get to tell everyone that's already scraping for pennies that there is now an additional unbudgeted cost. And then it's 'postponed' two days after the announcement and managers are flipping out that they cannot budget around this madness. I don't blame them. … Throw in the many UX issues that have been neglected for years (limit on jobs per workflow, concurrency groups canelling jobs instead of queuing, self-hosted runner versions only last a month or two before being rejected, hung logs, outages, no per second billing) and trying to slide in the announcement in December. It seems quite bold of GitHub. … ### molexx Jan 2, 2026 - Please stop applying breaking changes. Whilst they might well be 'best practice' and you might think you've informed us about them in plenty of time, real-world evidence shows this causes disruption and unhappy users.* We use Actions to deploy to production, and if we need a production deployment we NEED a production deployment, I do not want to take several hours out to investigate, fix and test changes to our action that was stable yesterday because of a requirement change you have force-applied to us. Whether you allegedly warned anyone about it months ago or not.

in a workflow file, you’re declaring a dependency. GitHub resolves it, downloads it, and executes it. That’s package management. ... Package managers are a critical part of software supply chain security. The industry has spent years hardening them after incidents like left-pad, event-stream, and countless others. Lockfiles, integrity hashes, and dependency visibility aren’t optional extras. They’re the baseline. GitHub Actions ignores all of it. … The core problem is the lack of a lockfile. Every other package manager figured this out decades ago: you declare loose constraints in a manifest, the resolver picks specific versions, and the lockfile records exactly what was chosen. GitHub Actions has no equivalent. Every run re-resolves from your workflow file, and the results can change without any modification to your code. Research from USENIX Security 2022 analyzed over 200,000 repositories and found that 99.7% execute externally developed Actions, 97% use Actions from unverified creators, and 18% run Actions with missing security updates. The researchers identified four fundamental security properties that CI/CD systems need: admittance control, execution control, code control, and access to secrets. GitHub Actions fails to provide adequate tooling for any of them. A follow-up study using static taint analysis found code injection vulnerabilities in over 4,300 workflows across 2.7 million analyzed. Nearly every GitHub Actions user is running third-party code with no verification, no lockfile, and no visibility into what that code depends on. … ``` // Simplified from actions/runner ActionManager.cs ... // Resolution happens on GitHub's server - opaque to us var downloadInfo = await GetDownloadInfoFromGitHub(action.Reference); // Download and extract - no integrity verification var tarball = await Download(downloadInfo.TarballUrl); Extract(tarball, $"_actions/{action.Owner}/{action.Repo}/{downloadInfo.Sha}"); // If composite, recurse into its dependencies var actionYml = Parse($"_actions/{action.Owner}/{action.Repo}/{downloadInfo.Sha}/action.yml"); if (actionYml.Type == "composite") { // These nested actions may use mutable tags - we have no control await PrepareActionsRecursiveAsync(actionYml.Steps, depth + 1); } } ``` … Even setting lockfiles aside, Actions has other issues that proper package managers solved long ago. **No registry.** Actions live in git repositories. There’s no central index, no security scanning, no malware detection, no typosquatting prevention. A real registry can flag malicious packages, store immutable copies independent of the source, and provide a single point for security response. The Marketplace exists but it’s a thin layer over repository search. Without a registry, there’s nowhere for immutable metadata to live. If an action’s source repository disappears or gets compromised, there’s no fallback. … ### How Did We Get Here? The Actions runner is forked from Azure DevOps, designed for enterprises with controlled internal task libraries where you trust your pipeline tasks. GitHub bolted a public marketplace onto that foundation without rethinking the trust model. The addition of composite actions and reusable workflows created a dependency system, but the implementation ignored lessons from package management: lockfiles, integrity verification, transitive pinning, dependency visibility. This matters beyond CI/CD. Trusted publishing is being rolled out across package registries: PyPI, npm, RubyGems, and others now let you publish packages directly from GitHub Actions using OIDC tokens instead of long-lived secrets. OIDC removes one class of attacks (stolen credentials) but amplifies another: the supply chain security of these registries now depends entirely on GitHub Actions, a system that lacks the lockfile and integrity controls these registries themselves require. A compromise in your workflow’s action dependencies can lead to malicious packages on registries with better security practices than the system they’re trusting to publish. … GitHub closed the feature request. GitHub’s design choices don’t just affect GitHub users. Forgejo Actions maintains compatibility with GitHub Actions, which means projects migrating to Codeberg for ethical reasons inherit the same broken CI architecture. The Forgejo maintainers openly acknowledge the problems, with contributors calling GitHub Actions’ ecosystem “terribly designed and executed.” But they’re stuck maintaining compatibility with it. Codeberg mirrors common actions to reduce GitHub dependency, but the fundamental issues are baked into the model itself. GitHub’s design flaws are spreading to the alternatives.

- **Nx "s1ngularity" (August 2025):** Attackers compromised the popular Nx monorepo build system by publishing malicious npm packages via a GitHub Actions exploit, injecting credential-harvesting malware that stole SSH keys, .env** ** files, wallets, and API tokens. This attack affected over 2,000 repositories. … ### 6. Unpinned or Tag-Based Third-Party Actions This is one of the most prevalent and dangerous supply chain risks in GitHub Actions. Despite causing nightmare scenarios for tens of thousands of users this year, most developers still do not pin their actions properly. According to Wiz, only 3.9% of repositories pin 100% of their third-party Actions to an immutable commit SHA hash. … ### 7. Use of Vulnerable Third-Party Actions Third-party GitHub Actions are convenient accelerators but introduce significant supply chain risks. These actions execute with the same permissions as your workflow, granting them potential access to sensitive secrets, tokens, and repository data. Like the previous security flaw, it’s an attack vector for supply chain attacks. As seen in the 2025 tj-actions/changed-files incident (CVE-2025-30066), a compromised action leads to attackers injecting code to exfiltrate secrets, escalating privileges, or deploying malware directly into your pipeline. With recurring incidents during the past year, proactive governance is essential to mitigate these threats.

#### GitHub Action Cons - The free host runners are **slow**. The free host virtual machines are about 4-5x slower than my mini-PC (i7-13700H) that hosted my Jenkins server - To mitigate the performance different – it was very simple to run each “compiler” on its own runner in parallel – so my overall build times only went from ~30min to ~40min.

- Everything that goes into `main` must pass all tests. - Trivial mistakes (formatting, unused deps, lint issues) should be fixed automatically, not cause failures. - The artifacts we test with in CI should be the exact ones we release. - CI should complete quickly (to keep developers happy). GitHub Actions technically allows all of this—but setting it up is a frustrating mess, full of hidden gotchas, inconsistent behavior, and a debugging experience that makes me question my choices. … This is just one of many instances which I believe is the root of what makes the github actions security model so obscure: there are too many pitfalls accompanied by exceptions that you have to account for. Clearly the system is very powerful and allows you to do many things but it also expands the attack surface for breaking things. As far as I can tell I'm not alone in this. Another instance of the same problem I ran into is when I read this paragraph where they recommend that you don't use self-hosted runners in public repositories: … ### Docker and Github Actions, an Unholy Combination If you thought GitHub Actions was bad, try mixing in Docker. GitHub lets you run jobs inside a container. This is great in theory—you can prepackage dependencies into a dev container instead of installing them every run. In practice: - File permissions break constantly. A container builds files as one user, but GitHub runners may use another (different uid and gid) to run it. So it may be unable to either access the files in the container or in the github workspace and temporary host directories that get mounted. - The

Discussions and Stack Overflow. These posts address prevalent issues in such ecosystems, including security, breaking changes, obsolescence, and dependency. We empirically demonstrate the prevalence of these issues in GitHub Actions. Our thematic analysis on GitHub Discussion posts and Stack Overflow questions revealed that Security Vulner- ability is the most prevalent issue in the GHA ecosystem, followed … influences the reliance on Marketplace versus Local Actions. ... platform provides a Marketplace for sharing and reusing open-source Actions, there are still many repositories that prefer to maintain their own GHA locally within their repositories. The survey analysis conducted by the authors revealed some challenges GitHub users face using the Marketplace, where 7 out of 25 participants found it difficult

GitHub Actions has grown massively since its release in 2018; in 2025 alone, developers used 11.5 billion GitHub Actions minutes in public and open source projects, up 35% year over year from 2024. At the same time, this has not been without its growing pains, and you’ve made clear to us what improvements matter most: faster builds, improved security, better caching, more workflow flexibility, and rock-solid reliability. … ... This was not without its share of pain; it slowed the pace of feature work and delayed progress on long-standing community requests. ... ### Larger caches for bigger projects and dependency-heavy builds Repositories can now exceed the previous 10GB cache limit, removing a long-standing pain point for teams with large dependencies or multi-language monorepos. For teams with larger codebases or complex build pipelines, the old 10GB GitHub Actions cache limit often meant build dependencies were evicted before they could speed up your next workflow run, leading to repeated downloads and slower builds. This release was only possible due to our architecture rework and fulfills a request from the community, particularly among some of our largest users. … ### More performance and platform improvements shipped in 2025 We also made progress on the strong foundation laid earlier this year, including arm64-hosted runners for public repositories, macOS 15 and Windows 2025 images (now generally available), Actions Performance Metrics (also generally available), and Custom Image support in public preview. These releases are designed to improve day-to-day workflow quality and remove long-standing friction.

It was also interesting to hear the other side of the story, especially on why things took too long (big internal infrastructure migration at GitHub) or why it feels like the product is not being improved (we both agreed that GitHub should improve their communication). ... Before I rant about GitHub Actions, I'd like to set the context on where this dissatisfaction comes from. My team consists of about 15 engineers constantly pushing to the main branch. Our code lives in a monorepo split per module, which, through trunk based development, gets deployed multiple times a day. … `web-app1` folder. So if my pull request only made changes in `api1` I will never be able to merge my pull request! 🤯 In these two GitHub threads 1, 2 you can see the impact. The bottom line is, that working around this limitation is hacky, difficult to maintain, and costly since you have to run additional pipelines just to determine if a pull request can be merged or not! GitHub should not rely on specific names for the required checks. They can just say - all checks have to pass before you merge. That way, whatever pipelines and checks your pull requests have triggered will be considered mandatory. It's been almost 3 years since these issues were raised, and nothing changed yet! My impression is that when your pipeline grows, it becomes more and more difficult to manage it with GitHub Actions. Here is an example workflow that can be called from other workflows, can be triggered manually, and triggers when someone pushes to the master branch. … What I notice doing more and more is that I have to add lots of if statements such as this. ` if: ${{ github.event_name == 'push' || inputs.target_environment == 'production' }}` While I could split this into multiple workflows with different triggers, then I'm getting more and more files to maintain. A workflow reuse should be a one-liner but I always have to write more lines and a lot of duplicated statements such as workflow name, `secrets: inherit` etc. Our `.github` folder already contains 30+ files. Another pitfall that happens often is the `needs` clause. When you are refactoring and removing jobs, it's easy to forget to update this clause and subsequent steps. While there are linters available, they are not perfect. The sad part is that I can only see mistakes when I push the workflow, I'd expect to know about this way earlier. … Of all the pain points, this is the worst one. It seems that GitHub doesn't care about fixing any of these issues or improving its product. Some of the threads have been open for years without any action taken by GitHub. A lot of these issues have been recently closed by GitHub causing a backlash from the community. There are no signs that these will be addressed based on their public roadmap. Considering all the problems listed, with the lack of motivation from GitHub I'd think twice before using GitHub Actions again. The CI/CD product space offers a lot of options such as Gitlab, Jenkins, TeamCity, etc.