Closed joycebrum closed 1 year ago
Thanks!
I'll look into the PR as soon as I find the time.
Hi @joycebrum,
I think I understand the basic rationale here, and using specific versions are good, but exactly what version the hashes points to is a bit non-transparent for human readers after the change... Doesn't this just open the door for another type of attack, like a malicious commit/PR like:
- uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v4.0.1
...while in fact, the hash points to the outdated v3.5.2
tag that contains a critical flaw that leaks credentials, not the brand new 4.0.1 (completely made up example)? Is there any better ways to verify this, than to manually check that every version and hash checks out?
Obviously out of scope for this issue, but would't a new syntax for specifying version AND hash, where both are verified be a safer solution:
- uses: actions/checkout@v4.0.1=8e5e7e5ab8b370d6c329ec480221332ada57f0ab # imaginary syntax
Is your feature request related to a use case or a problem you are working on? Please describe.
I 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, dockerfiles and shell scripts dependencies.
Describe the solution you'd like
To mitigate this threat vectors we can basically hash pin GitHub Workflow actions.
Also it might be important to notice that the dependabot, that seems to be already enabled, is able to update both the hash and the comment version related to it.
Together with this issue I'll also suggest a PR with the changes since they are quite simple.
Any questions or concerns just let me know. Thanks!
Additional context
A tag renaming attack is a type of attack whereby an attacker: