Securing use of third-party GitHub actions #26310
-
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. This is especially troubling for third-party actions which are invoked in an authenticated context. They could not only access the 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. |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments
-
This could be utterly beneficial for Enterprise organizations. |
Beta Was this translation helpful? Give feedback.
-
At the very least, providing some kind of manifest/lock file that could be defined in the |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
|
Beta Was this translation helpful? Give feedback.
-
Yes, that would work. We have done something similar for other things (for example using It wouldn’t solve the versions used in actions we consume, though. Only the versions we reference in our own actions. |
Beta Was this translation helpful? Give feedback.
-
Moved this discussion here: Securing use of third-party GitHub actions · Discussion #18103 · github-community/community · GitHub |
Beta Was this translation helpful? Give feedback.
Moved this discussion here: Securing use of third-party GitHub actions · Discussion #18103 · github-community/community · GitHub