Lock Your GitHub Actions

Already__Taken

Quoting someone else's blog I've forgotten but you're trading the trust in the repo owner not moving a tag for trusting whoever merges the commit hash to have checked that's a release in the repo you want and not _some_ forks commit. All forks on github are the same repo you can pin any commit, merged upstream or not. IMO Github should make Immutable tags mandatory to publish on https://github.com/marketplace

SchemaLoad

Are people finding a real need for importing and updating git actions? Aren't they usually just running a one line bash command? I'd just copy paste the action in to your config so it's fully locked and under your control rather than importing some opaque script from a no name github user.

ezekg

Does this prevent one of the locked dependencies not locking their own dependencies and pulling in a malicious and replaced tag?

woodruffw

The advice here is really great (as I'd expect from Hugo), but as the maintainer of zizmor I want to note some caveats with the current iteration of workflow lockfiles: - They only lock normal action calls. If your workflows invoke other reusable workflows, you need to keep those hash-pinned manually for now. - Composite actions are not themselves locked. Instead, they get locked transitively through their callsites i.e. the workflows that call them. This makes any individual caller that uses lockfiles safe, but it also makes the current `gh actions-lock` default unsafe (since it removes hash-pins from the composite action itself, meaning that any external caller that invokes the action loses their transitive pinning). - Other forms of `uses:` clauses, like Docker images, are also not currently locked via the lockfile. And the same for forms of interior mutability (like an action running `npx ...` under the hood, although the latter is fully outside of GitHub's control to prevent. But these mean that you can't assume that a fully locked Actions setup is in fact 100% immutable. I hope they address these gaps soon, because it's otherwise an excellent (and long-awaited) feature.

lukasschwab

Are there clear reasons to prefer this over just pinning a commit SHA?

aleaph

So "SHA pinning with version reference in a comment" with extra steps, got it

gbraad

I undrrstand this looks cleaner and more intuitive, but you still have the risk of running a workflow with malicious/compromised actions, like manually, or locally with act, if you do not verify the lockfile as part of the workflow or preceded by an extra workflow step. This should be something that the runner ideally should handle (as part of the platform). This still is a workaround, just like the sha pinning. I only use vendor upstream actions, like github's or forks in our own org.

latexr

I remember reading (but haven’t verified) that even using a specific SHA instead of a tag isn’t a guarantee with GitHub Actions, because the Action itself may have a dependency which does not pin to a SHA, thus making you vulnerable all the same. This lock file strategy does not appear to guard agains that, it seems to be what we had before but trades a bit more readability in one file for an extra (more complex) lock file. Not a trade-off I want to make (but you do you). Personally I found the risk of running someone else’s GitHub Action in my repo to not be worth it. Even GitHub’s own Action to checkout repos is way more complex than I need it to be and last I checked had dependencies which could be targeted. I opt instead to not run any third-party Actions (not even GitHub’s official ones) in my repos.

klodolph

I think my main advice is to avoid GH actions at all, unless avoiding them is somehow painful. There is just a long bad history here.

carterschonwald

at this point im seriously pondering how to build a dvcs code forge thats not dog shit, versions its own state, and actually is semantically grounded rather than a rails app gone awry

transitivebs

big fan of actions-up for doing this: https://github.com/azat-io/actions-up

edelbitter

So instead of specifying a SHA1 hash of some commit and change it rarely enough to just check manually, now every developer needs to unsafe-eval some 476 transitive dependencies of the helper that fixes the lockfile? I wonder at which point it gets easier to just have a nice stdlib again, and not deal with tons and tons of version changes in packages across 3 different language ecosystems.

numbsafari

Shouldn’t we all just be vibe coding our own actions instead of using the marketplace ones? Is SaaS dead yet, or what? /s This is a step in the right direction, but it’s not even close to a complete solution. And what am I doing installing a plugin to use this? It should just be part of GH, so I can install that and not have yet another source of dependency management to lock down.

insanitybit

ctrl + f "zizmor" 8 found I endose this article.

Pxtl

If GitHub really cared about security they could fix this tomorrow by declaring any tag linked to an action immutable. They don't because they don't. Anybody who's ever moved a git tag knows the ergonomics of doing so are so awful that you're obviously not supposed to be doing it.