Github is the world’s largest source code host, having over 100 million developers and more than 420 million repositories.

One of the most utilized feature of Github is Github Actions. GitHub Actions makes it easy to automate workflows, offering one of the best Continuous Integration and Continuous Deployment (CI/CD).

If you have worked on any software as a solo developer, for a company or contributed to open source making using of Github, you have most likely used github actions. If this is your first time hearing about Github Actions, read more about it here.

Github actions can be shared publicly for others people to make use of. There are thousands of shared public actions which offers different and useful functionalities, so you do not have to write them yourself.

Example of GitHub Actions available are:

Here comes the problem!

Workflow users may reference this available actions in multiple ways

Using release tags

steps:
    - uses: actions/checkout@v4 # using release tags

Using branch name

steps:
    - uses: actions/checkout@master # using branch name

Using commit sha

steps:
    - uses: actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f # using commit sha

Have you seen the problem? bad actors

A lot of trending actions found at the marketplace are using secrets to perform their tasks. Some may require username, password or access token for different functionalities, like authentication, to able to use some services.

For example, in using the above referenced action actions/docker-login

name: ci

on:
  push:
    branches: main

jobs:
  login:
    runs-on: ubuntu-latest
    steps:
      -
        name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ vars.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

I doubt if users of Github Actions go through in details the source code of this kind of actions to see how their credentials is being used.

We in most times trust this actions creator, what if the the publisher we trust decides to let someone else support this code (thats Open Source thing right? Collaboration!) ?

Any codebase maintainer can update branch or tags, THIS IS THE PROBLEM

Look at this scenario

  • Maintainer A (with good intent) pushes code to a branch (often main or master) or with a tag (has commit abc123)
  • Maintainer B (with bad intent) makes code changes update the branch or tag with his code changes (new commit def456)

Each Git commit receives a calculated SHA value, which is unique and immutable.

Git tags can be deleted or moved

WE HAVE A PROBLEM in our workflow now

steps:
    - uses: actions/some-action@<branch_name> # using branch

When we trigger our workflow, our workflow runs will use updated code from the action’s branch (NOW OUR WORKFLOW will work with THE BAD CODE)

steps:
    - uses: actions/some-action@v<tag> # using tag reference

Just like the above, if we use tags, further updates to this actions will be used during our workflow run

USING FULL COMMIT SHA IS THE ONLY WAY TO BE SAFE

steps:
    - uses: actions/some-action@<commit_sha> # using tag reference

Using commit sha, means every time our workflow runs we make use of the same action code.

The caveat to using commit SHA is that our workflow will NOT have access to updated action code. We might have to manually update this SHA to latest versions if we really want to use an updated action code functionality.

Using our scenario, when we use actions/some-action@abc123 we are SAFE from the bad code vulnerabilities introduce by the new commit def456.

Is this even a real problem to be bothered about?

Well, if anything, we should learn from history,

  • At around 4:00 PM March 14th, 2025 UTC, a popular GitHub Action (tj-actions/changed-files) was fully compromised. Someone committed a base64-encoded payload that runs a script that in turn prints out encoded secrets read about the incident.

pleading