-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GitHub Actions: Consider hardening setup against CVE-2020-15228 #1246
Comments
Additional hardening we might consider is in the actions we use. AFAICT an Action release on the marketplace corresponds to a tag in the repository that publishes the action, which leaves users open to malicious maintainer attacks - tags are not immutable, so a repo owner (or attacker) can replace the tag and point to a malicious version of the action. GitHub allows us to restrict actions to either: only use actions defined in our org, only allow a predefined list of actions, or allow all actions. |
Good observation, @joshuagl! Here are some ideas to reduce the attack surface:
|
You guys are really thinking this through. Very impressive! 👏🏽 |
Re-add coverage publishing on coveralls.io, formerly performed by Travis CI (prior to theupdateframework#1242), using the coveralls cli tool according to the documentation: https://coveralls-python.readthedocs.io/en/latest/usage/configuration.html#github-actions-gotcha **Considered alternatives:** - Official coveralls GitHub action, which does not seem to work well for Python: coverallsapp/github-action#4 coverallsapp/github-action#30 - Inofficial fork of that action, which seems to work better but had issues finding the coverage data in the tests folder, or the covered code respectively. https://github.com/AndreMiras/coveralls-python-action Besides aforementioned issues of these actions the use of cli tools from curated package managers seems slightly preferable over actions from the GitHub Marketplace (see theupdateframework#1246). Signed-off-by: Lukas Puehringer <[email protected]>
Another reason to distrust 3rd-party Actions – they can push commits (and tags?) to the repository[1]. Furthermore, possibly due to the underlying shared object storage of GitHub, it seems that git activity on forks may have unintended consequences on the forked repo. So far as I can tell, this is not yet confirmed, but the Caddy Web Server seems to have had a release made – and pushed to the Go module proxy – by a tag being pushed to a fork of their repo[2]. |
Re-add coverage publishing on coveralls.io, formerly performed by Travis CI (prior to theupdateframework#1242), using the coveralls cli tool according to the documentation: https://coveralls-python.readthedocs.io/en/latest/usage/configuration.html#github-actions-gotcha **Considered alternatives:** - Official coveralls GitHub action, which does not seem to work well for Python: coverallsapp/github-action#4 coverallsapp/github-action#30 - Inofficial fork of that action, which seems to work better but had issues finding the coverage data in the tests folder, or the covered code respectively. https://github.com/AndreMiras/coveralls-python-action Besides aforementioned issues of these actions the use of cli tools from curated package managers seems slightly preferable over actions from the GitHub Marketplace (see theupdateframework#1246). Signed-off-by: Lukas Puehringer <[email protected]>
GitHub's Security Lab have published some research and recommendations on securing GitHub Actions workflows:
Haven't had chance to dig into this at all, but found an experiment in "Verifiable GitHub Actions" verifyme |
Re-add coverage publishing on coveralls.io, formerly performed by Travis CI (prior to theupdateframework#1242), using the coveralls cli tool according to the documentation: https://coveralls-python.readthedocs.io/en/latest/usage/configuration.html#github-actions-gotcha **Considered alternatives:** - Official coveralls GitHub action, which does not seem to work well for Python: coverallsapp/github-action#4 coverallsapp/github-action#30 - Inofficial fork of that action, which seems to work better but had issues finding the coverage data in the tests folder, or the covered code respectively. https://github.com/AndreMiras/coveralls-python-action Besides aforementioned issues of these actions the use of cli tools from curated package managers seems slightly preferable over actions from the GitHub Marketplace (see theupdateframework#1246). Signed-off-by: Lukas Puehringer <[email protected]>
I'd like to close this:
That leaves us with (I think) just some configuration, like allow only actions created/hosted by GitHub: I think this makes sense since we currently only use githubs own actions (and should have a high bar for using actions made by others). Would one of the org admins like to make that call and maybe flick the switch in settings? |
Done! Thanks for the research and for creating two more specific issues. Closing.. |
Description of issue or feature request:
#1242 added a GitHub Actions based CI workflow . GitHub Actions has a moderate injection vulnerability (CVE-2020-15228) against which we should consider hardening our setup.
Current behavior:
No particular hardening against CVE-2020-15228
Expected behavior:
Assess necessity and harden against CVE-2020-15228.
@jku proposes a strategy in #1195 (comment) also described in https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
The text was updated successfully, but these errors were encountered: