Want to learn how to build your own GitHub Actions? Click here

Ensure your GitHub Actions are pinned to a SHA

01 Jan 2021 in Action Spotlight

Use this GitHub Action as a continuous integration check to ensure that all the actions you depend on are pinned to a SHA

It’s the first of January and we’re getting started with a new series, the GitHub Action Spotlight.

There are a ton of awesome GitHub actions out there, and I struggled to decide which to feature first before settling on ensure-sha-pinned-actions.

Why is it important?

One of the biggest concerns around GitHub Actions is the dependence on actions that were not authored by a trusted source. There was not an official Docker build and publish action for a long time, which meant that we had to trust a third party with our DockerHub username and password.

We could audit the code at that point in time, but the general advice was to point at the main branch of an action to get updates as they are published. This meant that the author could push updates at any time and we’d accept them without review.

GitHub themselves recommended switching to depend on a tag, but tags can be updated to point at a different SHA too, which meant that any malicious action author could still steal your secrets.

The only safe solution is to pin to a specific commit SHA, where you can audit the code and be sure that it cannot change. This is not user friendly at all, as you’d have to go through your actions and work out which SHA to use for each action.

In January 2020, I built a CLI tool to improve your GitHub Actions security which automatically converts an entire workflow to pin their dependencies to a specific sha. This is a great start as it reduces the barrier to entry to using a sha rather than a branch.

This is only half the battle though. Although there is tooling available to automatically pin to a sha, it can’t force people to use it. That’s where on ensure-sha-pinned-actions comes in.

How does it work?

ensure-sha-pinned-actions is designed to run on push to every branch. It will loop through each workflow in the .github/workflows directory, checking every step contained within a job. If the step contains a uses key, it will validate that everything after the @ is a valid sha.

usesPasses
@main
@v1
@v1.1.0
@9a77932de62ee4199961f1381b64d7d282daa3b7

If any commits are pushed that use a non-sha action, the workflow will fail and send a notification to the repository owner.

Useful links