GitHub Actions update: Helping maintainers combat bad actors

GitHub Actions is a powerful, flexible CI/CD service that gives developers the ability to automate all of their software workflows. Developers have built amazing things with GitHub Actions, and the CI/CD service has dramatically accelerated developer productivity. At the same time, as GitHub Actions has grown, we’ve unfortunately also seen a wide variety of bad actors abusing Actions, affecting service performance, and causing denial of service to open source projects.

The trustworthiness of the platform is crucial, and our team is committed to developer productivity and to Actions performing the way we intended. Cryptomining on Actions is not new, and we’ve been fighting abusers since the beginning. However, as the price of coins has gone up, the number of abusers has escalated. We’ve spent thousands of hours combating abuse and implemented dozens of different mitigations to detect and prevent it. Ensuring Actions remains a trusted choice for developers’ automation and CI/CD needs is a top priority for our team, and we’ll continue to put safeguards in place to get ahead of bad actors.

We wanted to take a moment to discuss one of the latest targeted abuse attacks that affected a lot of maintainers on GitHub and explain what we’re doing to fix it.

GitHub Actions cryptomining abuse

The recent surge in cryptocurrency prices has driven a significant increase in targeted abuse across CI providers. At GitHub, we’ve seen a variety of vectors being exploited. One of these is pull requests from forks being used by bad actors to run mining code on upstream repositories. This obviously has a negative impact on repository owners whose legitimate pull requests and accounts may be blocked as a result of this activity.

To prevent this, we’re delivering two changes to how we treat pull requests from public forks in Actions to help maintainers.

New features to help protect maintainers

First, we’re updating how we assess reputation on Actions. Specifically, if we determine an Actions run to be abusive or against our terms, our enforcement will be directed at the account hosting the fork and not the account associated with the upstream repository. The goal is to prevent maintainer accounts from being flagged and blocked due to these bad actors.

Second, pull requests from first-time contributors will require manual approval from a repository collaborator with write access before any Actions workflows run. When a first-time contributor opens a pull request, they’ll see a message that a maintainer must approve their Actions workflow before it will run.

When a maintainer views the pull request, they’ll see a button in the merge box asking them to “Approve and run” the workflows.

Once a collaborator with write access has reviewed the changes, they can approve the workflows to run for the current commit only. If the pull request is updated to a new commit, a new approval will be required.

Based on conversations with several maintainers, we feel this step is a good balance between manual approval and existing automated workflows. This will be the default setting and, as of now, there is no way to opt out of the behavior, but we do have plans to implement a few additional settings to provide more flexibility. However, we want to hear what you think, and we encourage any maintainers affected by this change to give us feedback.

What’s next

We’re thrilled to see the growth of GitHub Actions and its continued adoption by open source projects and enterprises alike. Providing a robust and safe platform for our community is imperative to keeping our customers’ trust, and we’re working hard to minimize the impact of abuse on our community. Part of this includes providing you with tools and features like this to protect yourself.

Check out our documentation to learn more about approving workflow runs from public forks.

Written by

Chris Patterson

@chrispat