Securing use of third-party GitHub actions

In light of GitHub's commitment to npm ecosystem security | The GitHub Blog – I am wondering how GitHub plans to ensure the GitHub actions ecosystem also remains secure in the event of third-party action repository takeovers. As suggested in Security hardening for GitHub Actions - GitHub Docs – the safest way at the moment is to pin any third-party actions to a commit SHA, but unfortunately most documentation on GitHub and in third-party actions suggest to pin to a major version (e.g. @v1), which means it will automatically pull in subsequent tags for that major version.

This is especially troubling for third-party actions which are invoked in an authenticated context. They could not only access the GITHUB_TOKEN, but it could also compromise cloud-accounts such as AWS if precautions are not taken.

These are problems that have already been solved in other ecosystems, through things like caching layers (to guarantee the resource does not change), multi-factor verification when publishing new versions of a package, and ensuring that previously published packages cannot be modified. At the very least, it seems that GitHub should promote security best practices in all places in their documentation, instead of expecting someone to find and read the security section. Even better if this could be enforced through a process or convention.

PS: this is even more of a nightmare when using an action that itself references other actions. The only way to get around that is to fork the action and maintain it yourself, or copy the action into your repository.

5 Likes

This could be utterly beneficial for Enterprise organizations.
At the moment all the time have to do these assessments by ourselves for each new version and it is still tricky process.

2 Likes

At the very least, providing some kind of manifest/lock file that could be defined in the .github folder, which would apply to all actions (even those referenced within actions), would be very useful. Currently we have to maintain commit SHAs across hundreds of workflow files in our monorepo and this would greatly improve that experience.

2 Likes

As the author of a couple of Actions I would suggest pinning to a full tagged version number like v1.1.0, pinning to a commit SHA is also fine if it is a tagged version. Nothing else is guaranteed to work and for my actions probably won’t due to use of Docker and GHPR.

I would like MFA but it must work easily in a release workflow.

I feel your pain! I don’t know if you’ve done this already, but you could create your own manifest file and read it into each workflow; I haven’t tried this but I guess it would work.

Each workflow would need to:

  • Use actions/checkout to clone the repo (incl manifest)
  • Read the manifest (maybe via run or github-script)
  • Store the manifest content as an env
  • Reference the relevant value in the uses value of each action
1 Like

Yes, that would work. We have done something similar for other things (for example using .nvmrc to read the Node version). I guess it is the best workaround for now, even though it adds a bit of complexity to our workflows.

It wouldn’t solve the versions used in actions we consume, though. Only the versions we reference in our own actions.