Hash pin github workflow dependencies

[joycebrum]

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:

• Hash pinning GitHub Workflow actions.
• Using a package-lock.json on npm installs.

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:

• 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 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
• Renovatebot

[vitaut]

Sounds like a good idea, PRs are welcome.

[dimztimz]

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.

[Frank-Buss]

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