Hash pin github workflow dependencies

[joycebrum]

Description

Hi @manugarg,

I would like to suggest another 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.

This means:

• Hash pinning GitHub Workflow actions.
• Using --require-hashes on pip installs.

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.

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.

Let me know if you are open to evaluate these changes and I'll submit the PR(s) ASAP. Also let me know if you rather use dependabot or renovatebot. I can also help on providing comparison information about them.

Any questions or concerns just let me know.

Thanks! Joyce

Additional Context

A tag renaming attack is a type of attack whereby an attacker:

• Hijack an action.
• Upload a malicious version.
• Replace existing tags with malicious versions.

A dependency-confusion attack occurs when an attacker:

• Find the name of a package that the victims wants to install
• Create an identically named package and publish it under the public or default registry.
• Assign the package with a higher version number to trick the package manager tool to download it from the public repo.

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) For more informations about the dependency-update tools: - [Dependabot][dependabot] - [Renovatebot][renovatebot]

[gabibguti]

Hello! Doing a follow up here on behalf of Joyce. If you agree on making a few changes to hash pin dependencies, let me know, I can support you by opening a PR! Otherwise, we can close the issue as not planned. I'll wait 2 more months.

[manugarg]

I am open to adopting the suggestions, but getting to implement them will take some more time. I'll happy to review the PRs in the meantime.