GitHub Actions is Vulnerable to Supply Chain Attacks

One of the most surprising things about the design for GitHub Actions is that it’s vulnerable to supply chain attacks. Most workflows do not have their actions locked to a specific revision. If a malicious change is made to a third-party action, that change will get pulled into the next build that runs for any projects using that action.

Even for the GitHub-provided actions, like actions/checkout, GitHub recommends using the mutable v3 tag in the README

- uses: actions/[email protected]

Without locking, the risk of a third-party action suddenly breaking builds is also increased.

Security Risks in Supply Chains

To address security risks in the supply chain of third-party packages, package managers need:

• a way to pin or lock a dependency to a specific version
• a way to easily update dependencies, ideally using semver notation

Without being able to lock to a specific version, malicious changes made to upstream packages are immediately propagated.

Without being able to easily update dependencies, security fixes won’t get picked up.

To reiterate, the best strategy for minimizing security risk related to supply chain issues is:

• lock dependencies so that upstream vulnerabilities aren’t immediately applied
• frequently update dependencies so that security fixes are quickly applied

Essentially, you neither want to be too fast or too slow with updating dependencies.

GitHub Supports Locking but Not Updating

Arguably, GitHub does support locking actions. Instead of actions/[email protected], you can use a specific commit, like actions/[email protected]

The problem with locking is that there isn’t a tool to update to later versions. Some third-party services may help with this, but it’s not built into GitHub Actions in any way.

Without being able to easily update to later versions, locking creates a risk of using outdated code, which actually could increase the risk of security vulnerabilities due to using outdated actions which may not have security fixes.

Locking Syntax

GitHub could fix this issue by allowing both a mutable ref and and locked version

- uses: actions/[email protected]
  ref: f095bcc56b7c2baf48f3ac70d6d6782f4f553222

Mint

We’re currently developing Mint, a new build/CI tool.

We have this issue on our list of mistakes not to make 😅

We’ll be sharing the first public preview of Mint at the end of May. Join us for one of the following sessions

🗓️ Tue May 30 at 4pm Eastern

🗓️ Wed May 31 at 10am Eastern

Or if you can’t make it but want to follow along, subscribe to our newsletter:

👉 https://rwx.com/newsletter