-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Hash pin github workflow dependencies #3449
Comments
Sounds like a good idea, PRs are welcome. |
IMO the change in the PR for hash-pinning is useless and possible counter-productive. You just hash-pinned actions owned by Github that execute on Github runners (inside a VM) for a repository that is hosted on Github. You are protecting who from who? You are protecting Github from Github? The paranoia about software security is reaching new heights. I can think of a scenario where this change actually creates a new security issue. Let's say that certain vulnerability is discovered in the action which is also fixed. With the hash-pinning you will not get the fix automatically, you will still use the outdated one. |
That's an interesting point for the "actions" workflows, they are probably pretty safe and might be useful to get the latest versions, if problems with old versions are found. But malicious software could be still introduced to it. Dependabot looks like a good compromise. Looks like it creates PRs for new workflows, and then they could be reviewed. But there was also the msys2 project. I would says it is not as safe as a project managed by github, and would feel more safe if it gets hash pinned. And dependabot will also report new versions. If someone else wants to pin down their used workflows, I wrote a script for it which automates it: https://gist.github.com/Frank-Buss/9eea494be56b4a0b04c4ac7d5a6e1292 BTW, the problem can be recursive, if some used workflow uses still non-pinned other workflows. I guess there is no perfect solution for this, other then creating an issue for this as well for the target repo, or (recursivly) forking it if they don't want to pin it. cc @rwxrob |
Description
I also would like to suggest a security practice recommended by the OpenSSF Scorecard which is to hash pin dependencies to prevent dependency-confusion, typosquatting and tag renaming attacks.
The change would only be applied to GitHub workflows dependencies.
This means:
I can submit one PR for each type of change above to be easier to review if you prefer. Just let me know if that's the case.
Along with hash-pinning dependencies, I also recommend adopting dependabot or renovatebot to help keep the dependencies up to date. Both tools can update hashes and associated semantic version comments.
Let me know if you are open to evaluate those changes and I'll submit the PR ASAP.
Any questions or concerns just let me know.
Thanks!
Additional Context
A tag renaming attack is a type of attack whereby an attacker:
A dependency-confusion attack occurs when an attacker:
A typosquatting attack is a type of attack whereby an attacker:
For more informations about the dependency-update tools:
The text was updated successfully, but these errors were encountered: