Page History

...

There are a number of security problems you have to be aware of. The 3rd-party actions and 3rd party dependencies are a huge security risk if not used appropriately (basically if you are using it as the examples suggest you are opened for easy exploitation by the action authors). If you do not "securely" add the actions you are ripe to any kind of uncontrolled "write" modifications to your repository (!) by 3rd-party action owners AND (as we've learned recently) by 3rd party dependencies you install in your build pipeline. One of the problems caused INFRA action to disable the "direct" use of 3rd-party actions at the organisation level (see the discussion), but there are many more risks that you have to be aware of. There are two critical security vulnerability reports opened by Jarek Potiuk 30th of December with GitHub actions - both of them triaged and awaiting for actions on the GitHub side. GitHub Security Lab who in December encouraged the users to  post their experiences is engaged as well.  Those issues can be all mitigated (for Apache Airflow implemented all mitigation) but they are not what most projects do. 

Mitigations:

If you decide to use GitHub Actions,  those are recommendations (there are varying opinions on sub-modules use though):

• NEVER use 3rd-party actions directly in your worfklows - use the "submodule" pattern. Examople PR Tobiasz Kędzierski  opened in SuperSet showing how this could be done. Also the ASF INFRA allow-listed some of the popular Actions out there - including my "cancel workflow" action, but I there is no public list of those available. The nice things about submodules is that it does not bring action code to your repo, they link to commit hashes of the actions, and that it integrates well with GitHub review process so that committers have bigger chance to review the changes before they are merged. By using submodules, you are automatically following the GitHub recommendations for hardening of security for 3rd-party actions.
• ALWAYS add "persist-credentials: false" to all your checkout actions. This is not done by default and is a huge security risk because it leaves your repository (and hundreds of thousands others) open to 3rd-party dependencies to modify your repository (!) if you have any kind of "master" builds enabled. This is a "hidden" feature of checkout action that is not at all obvious, but it leaves write access to your repository widely open to any code that you install during the build process. This is a very dangerous default.
• NEVER directly run code that might come with "forked" PRs in your workflows directly. There are certain exotic (but useful) workflows  that are dangerous. For example "workflow_run" that you might need to cancel duplicate workflow. Those workflows by default run with "master" code, but sometimes you might need to checkout the incoming PR code for those. The host environment can have access (in various ways) to "WRITE" GITHUB_TOKEN that has permission to modify your repository WITHOUT RESTRICTION NOR NOTIFICATION. NEVER run the code that is checked out from the PR in your host environment. If you need to, run them in Docker Container to provide isolation from the host environment to avoid the "write" access to leak to users who prepare such a PR from their fork.
• NEVER install and run the 3rd-party dependencies in host of your build workflow code. Again there are ways those dependencies can obtain "WRITE" GITHUB_TOKEN and change anything in your repository without your knowledge.  There arevery common "schedule" and  "push" workflows that are especially prone to such abuse. Those run with "WRITE" access and again - there are ways to obtain the GitHub Token by the actions and code that runs in your workflow. If you execute any 3rd-party code, run it in Docker containers to keep isolation from your "build" host environment to avoid the "write" access to leak to those 3rd-parties.

...