haraldk / TwelveMonkeys

TwelveMonkeys ImageIO: Additional plug-ins and extensions for Java's ImageIO
https://haraldk.github.io/TwelveMonkeys/
BSD 3-Clause "New" or "Revised" License
1.9k stars 313 forks source link

Hash Pin Github Workflows #748

Closed joycebrum closed 1 year ago

joycebrum commented 1 year ago

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:

A [typosquatting attack][typosquatting] is a type of attack whereby an attacker: - Create a malicious package - Publish it with a similar name of a known package (example: numpi instead of numpy)
haraldk commented 1 year ago

Thanks!

I'll look into the PR as soon as I find the time.

haraldk commented 1 year ago

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