After tj-actions hack, I put together a little tool to go through all of github actions in repository to replace them with commit hash of the version<p><a href="https://github.com/santrancisco/pmw">https://github.com/santrancisco/pmw</a><p>It has a few "features" which allowed me to go through a repository quickly:<p>- It prompts user and recommend the hash, it also provides user the url to the current tag/action to double check the hash value matches and review the code if needed<p>- Once you accept a change, it will keep that in a json file so future exact vesion of the action will be pinned as well and won't be reprompted.<p>- It let you also ignore version tag for github actions coming from well-known, reputational organisation (like "actions" belong to github) - as you may want to keep updating them so you receive hotfix if something not backward compatible or security fixes.<p>This way i have full control of what to pin and what not and then this config file is stored in .github folder so i can go back, rerun it again and repin everything.
This has some good advice, but I can't help but notice that none of this solves a core problem with the tj-actions/changed-files issue: The workflow had the CAP_SYS_PTRACE capability when it didn't need it, and it used that permission to steal secrets from the runner process.<p>You don't need to audit every line of code in your dependencies and their subdependencies if your dependencies are restricted to only doing the thing they are designed to do and nothing more.<p>There's essentially nothing nefarious changed-files could do if it were limited to merely reading a git diff provided to it on stdin.<p>Github provides no mechanism to do this, probably because posts like this one never even call out the glaring omission of a sandboxing feature.
Timely article... I recently learned about self-hosted runners and set one up on a Hetzner instance. Pretty smooth experience overall. If your action contains any SSH commands and you'd like to avoid setting up a firewall with 5000+ rules[0], I would recommend self-hosting a runner to help secure your target server's SSH port.<p>[0] <a href="https://api.github.com/meta" rel="nofollow">https://api.github.com/meta</a>
> Safely Writing GitHub Workflows<p>If you are looking for ways to identify common (and uncommon) vulnerabilities in Action workflows, last month GitHub shipped support for workflow security analysis in CodeQL and GitHub Code Scanning (free for public repos): <a href="https://github.blog/changelog/2025-04-22-github-actions-workflow-security-analysis-with-codeql-is-now-generally-available/" rel="nofollow">https://github.blog/changelog/2025-04-22-github-actions-work...</a>.<p>The GitHub Security Lab also shared a technical deep dive and details of vulnerabilities that they found while helping develop and test this new static analysis capability: <a href="https://github.blog/security/application-security/how-to-secure-your-github-actions-workflows-with-codeql/" rel="nofollow">https://github.blog/security/application-security/how-to-sec...</a>
I’ve been reviewing the third party Actions we use at work and seen some scary shit, even with pinning! I’ve seen ones that run arbitrary unpinned install scripts from random websites, cloning the HEAD of repos and running code from there, and other stuff.
I don’t think even GitHub’s upcoming “Immutable Actions” will help if people think it’s acceptable to pull and run arbitrary code.<p>Many setup Actions don’t support pinning binaries by checksum either, even though binaries uploaded to GitHub Releases can be replaced at will.<p>I’ve started building in house alternatives for basically every third party Action we use (not including official GitHub ones) because almost none of them can be trusted not to do stupid shit.<p>GitHub Actions is a security nightmare.
Glad this got posted. It's an excellent article from the Wiz team.<p>GitHub Actions is particularly vulnerable to a lot of different vectors, and I think a lot of folks reach for the self-hosted option and believe that closes up the majority of them, but it really doesn't. If anything, it might open more vectors and potentially scarier ones (i.e., a persistent runner could be compromised, and if you got your IAM roles wrong, they now have access to your AWS infrastructure).<p>When we first started building Depot GitHub Actions Runners [0], we designed our entire system to never trust the actual EC2 instance backing the runner. The same way we treat our Docker image builders. Why? They're executing untrusted code that we don't control.<p>So we launch a GitHub Actions runner for a Depot user in 2-5 seconds, let it run its job with zero permissions at the EC2 level, and then kill the instance from orbit to never be seen again. We explicitly avoid the persistent runner, and the IAM role of the instance is effectively {}.<p>For folks reading the Wiz article. This is the line that folks should be thinking about when going the self-hosted route:<p>> Self-hosted runners execute Jobs directly on machines you manage and control. While this flexibility is useful, it introduces significant security risks, as GitHub explicitly warns in their documentation. Runners are non-ephemeral by default, meaning the environment persists between Jobs. If a workflow is compromised, attackers may install background processes, tamper with the environment, or leave behind persistent malware.<p>> To reduce the attack surface, organizations should isolate runners by trust level, using runner groups to prevent public repositories from sharing infrastructure with private ones. Self-hosted runners should never be used with public repositories. Doing so exposes the runner to untrusted code, including Workflows from forks or pull requests. An attacker could submit a malicious workflow that executes arbitrary code on your infrastructure.<p>[0] <a href="https://depot.dev/products/github-actions">https://depot.dev/products/github-actions</a>
This is a great article, with many important points.<p>One nitpick:<p>> Self-hosted runners should never be used with public repositories.<p>Public repositories themselves aren't the issue, pull requests are. Any infrastructure or data mutable by a workflow involving pull requests should be burned to the ground after that workflow completes. You can achieve this with ephemeral runners with JIT tokens, where the complete VM is disposed of after the job completes.<p>As always the principle of least-privilege is your friend.<p>If you stick to that, ephemeral self-hosted runners on disposable infrastructure are a solid, high-performance, cost-effective choice.<p>We built exactly this at Sprinters [0] for your own AWS account, but there are many other good solutions out there too if you keep this in mind.<p>[0] <a href="https://sprinters.sh" rel="nofollow">https://sprinters.sh</a>
I support places that use GH Actions like its going out of style. This article is useful.<p>I wonder how we get out of the morass of supply chain attacks, realistically.
GHA Newbie here: what are all these 3rd-party actions that people are using? How complicated is your build / deployment pipeline that you need a bunch of premade special steps for it?<p>Surely it's simple: use a base OS container, install packages, run a makefile.<p>For deployment, how can you use pre-made deployment scripts? Either your environment is bespoke VPS/on-prem, In which case you write your deployment scripts anyway, or you use k8s and have no deployment scripts. Where is this strange middleground where you can re-use random third party bits?
These suggestions make a lot of sense.<p>At Namespace (namespace.so), we also take things one step further: GitHub jobs run under a cgroup with a subset of privileges by default.<p>Running a job with full capabilities, requires an explicit opt-in, you need to enable "privileged" mode.<p>Building a secure system requires many layers of protection, and we believe that the runtime should provide more of these layers out of the box (while managing the impact to the user experience).<p>(Disclaimer: I'm a founder at Namespace)
I feel like there was a desire from GH to avoid needing a "build" step for actions so you could use `use: someones/work` or whatever, `git push` and see the action run.<p>But if you think about it, the entire design is flawed. There should be a `gh lock` command you can run to lock your actions to the checksum of the action(s) your importing, and have it apply transitively, and verify those checksums when your action runs every time it pulls in remote dependencies.<p>That's how every modern package manager works - because the alternative are gaping security holes.
Been tracking this project for a while <a href="https://github.com/chains-project/ghasum">https://github.com/chains-project/ghasum</a> . It creates a verifiable checksum manifest for all actions - still in development but looks very promising.<p>Will be a good compliment to Github's Immutable Actions when they arrive.
> By default, the Workflow Token Permissions were set to read-write prior to February 2023. For security reasons, it's crucial to set this to read-only. Write permissions allow Workflows to inadvertently or maliciously modify your repository and its data, making least-privilege crucial.<p>> Double-check to ensure this permission is set correctly to read-only in your repository settings.<p>It sounds to me like the most secure GH Action is one that doesn't need to exist in the first place. Any time the security model gets this complicated you can rest assured that it is going to burn someone. Refer to Amazon S3's byzantine configuration model if you need additional evidence of this.
> Using Third-Party GitHub Actions<p>Maybe I'm overly pedantic, but this whole section seems to miss the absolutely most obvious way to de-risk using 3rd party Actions, review the code itself? It talks about using popularity, number of contributors and a bunch of other things for "assessing the risk", but it never actually mentions reviewing the action/code itself.<p>I see this all the time around 3rd party library usage, people pulling in random libraries without even skimming the source code. Is this really that common? I understand for a whole framework you don't have time to review the entire project, but for these small-time GitHub Actions that handle releases, testing and such? Absolute no-brainer to sit down and review it all before you depend on it, rather than looking at the number of stars or other vanity-metrics.
Step Security has a useful tool that aids in securing GitHub Actions here: <a href="https://app.stepsecurity.io/securerepo" rel="nofollow">https://app.stepsecurity.io/securerepo</a><p>Disclaimer: No conflict of interest just a happy user.
Shameless plug, I pushed a small CLI for detecting unpinned dependencies and automatically fix them the other day: <a href="https://codeberg.org/madsrc/gh-action-pin" rel="nofollow">https://codeberg.org/madsrc/gh-action-pin</a><p>Works great with commit hooks :P<p>Also working on a feature to recursively scan remote dependencies for lack of pins, although that doesn’t allow for fixing, only detection.<p>Very much alpha, but it works.
Great article!<p>I also found this open source tool for sandboxing to be useful: <a href="https://github.com/bullfrogsec/bullfrog">https://github.com/bullfrogsec/bullfrog</a>
your article inspired me
<a href="https://github.com/seanwevans/Ghast">https://github.com/seanwevans/Ghast</a>
still a WIP
The recommendation is not to interpolate certain things into shell scripts. Don't interpolate _anything_ into shell scripts as a rule. Use environment variables.<p>This combined with people having no clue how to write bash well/safely is a major source of security issues in these things.
I guess TL;DR just use ephemeral runners when self hosting? There are lots of solutions for that. Also would be nice for GitHub to do something on the security front (allowlist / blocklists if IPs, hosted, etc or at least just reporting on traffic)
The riskiest line in your repo isn’t in "src/", it’s in ".github/workflows/"<p>Self-hosted runners feel more secure at first since they execute jobs directly on machines you manage. But they introduce new attack surfaces, and managing them securely and reliably is hard.<p>At Ubicloud, we built managed GitHub Actions runners with security as the top priority. We provision clean, ephemeral VMs for each job, and they're fully isolated using Linux KVM. All communication and disks are encrypted.<p>They’re fully compatible with default GitHub runners and require just a one-line change to adopt. Bonus: they’re 10× more cost-effective.<p><a href="https://www.ubicloud.com/use-cases/github-actions">https://www.ubicloud.com/use-cases/github-actions</a>