In the world of CI/CD automation, GitHub Actions have become indispensable. But there's a troubling security pattern that many users don't know about: numerous popular GitHub Actions have release processes where the release commit does not belong to any branch on the action repository. This seemingly technical detail creates a significant security blind spot that makes it harder to verify if what you're using is trustworthy.
The Attack Vector We've Seen in the Wild
The severity of this issue became clear during the tj-actions and reviewdog security incidents. In these attacks, malicious actors exploited a clever technique: they updated existing tags to point to commits that weren't in the default branch. These were "imposter commits" — they weren't actually in the original repository but existed in a fork controlled by the attacker.
Why would attackers do this? It's simple: to evade PR reviews and bypass the scrutiny that comes with changing code in the default branch. By pointing tags to commits outside the default branch, or in a fork controlled by the attacker, they could inject malicious code while making it appear legitimate to casual observers.
Our Discovery: A Widespread Problem
At StepSecurity, we implemented detection capabilities to alert us whenever a release tag points to a commit not on any branch in the action repository. What we discovered surprised us: many legitimate, popular actions follow a release pattern that creates the same warning signs as these attacks.
Here's the typical workflow we found:
- Create a new branch specifically for the release
- Run ncc (Node.js compiler) to generate the dist folder with bundled code
- Create a new tag pointing to this commit
- Delete the branch
The result? When you look at these releases on GitHub, you see that familiar warning message: "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." For security-conscious users, this creates a dilemma — how can you distinguish between a legitimate release process and a potential security threat?
Examples from Popular Actions
Let's look at three examples of well-known GitHub Actions that follow this pattern:
Example 1: cloudflare/wrangler-action
https://github.com/cloudflare/wrangler-action/commit/da0e0dfe58b7a431659754fdf3f186c529afbe65
Used by over 43,000 public repositories, this action easily deploys cloudflare workers applications using wrangler and GitHub Actions. The release tag points to a commit that no longer has an associated branch, making verification challenging.
Example 2: slackapi/slack-github-action
https://github.com/slackapi/slack-github-action/commit/37ebaef184d7626c5f204ab8d3baff4262dd30f0
Another popular action, used by over 16K public repositories following the same release process. While the releases are trustworthy, the release pattern makes it hard to verify this at a glance.
Example 3: devcontainers/ci
https://github.com/devcontainers/ci/commit/8bf61b26e9c3a98f69cb6ce2f88d24ff59b785c6
A GitHub Action designed to simplify using Dev Containers in CI/CD systems, used by over 5K public repositories, has the same issue.
How StepSecurity Helps Protect Your Workflows
Recognizing both the security risks and the prevalence of this pattern, StepSecurity offers two key features to help our customers navigate this challenge:
1. Imposter Commit Detection
Our platform actively monitors your GitHub Actions usage. If you're using an action with a tag or commit SHA that isn't in the default branch, we trigger an alert. This detection helps you:
- Identify potentially compromised actions immediately
- Review actions that follow risky release patterns
- Make informed decisions about which actions to trust
2. StepSecurity Maintained Actions
We've taken action security a step further by creating secure, drop-in replacements for popular actions. Our maintained actions feature:
- Transparent release process: All releases are tied to commits in the main branch
- Security-first approach: Regular security audits and dependency updates
- Full compatibility: Designed as drop-in replacements requiring minimal configuration changes
- Trustworthy provenance: Clear audit trail for every release
Summary
The current state of GitHub Actions releases presents a real challenge for security-conscious organizations. While many legitimate actions use release processes that trigger security warnings, the same patterns can hide malicious activity.
By understanding these risks and implementing proper safeguards, we can continue to leverage the power of GitHub Actions while maintaining the security of our CI/CD pipelines.
We are hosting a webinar on 25th June at 10AM PST to discuss governance of 3rd party GitHub Actions where we will discuss this problem in more detail. Register here: https://us06web.zoom.us/webinar/register/WN_lWAj51A3TKav2bqWVJ4_EA#/registration
.png)
.png)
