Frozen deps should check for hash pinning

[laurentsimon]

The check currently looks for known files but does not parse them. It would be useful to enforce packages are pinned by hash for a program (not for a library).

This will require supporting several languages. It will be very time-consuming to migrate pinned by version to pinned by hash manually, so we will need some tooling to automatically update the files for project owners.

[laurentsimon]

Several aspects:

1. Language specific deps files
2. Commands in Makefile, scripts, docker images, etc using package managers: E.g. go get pkg@vXXX:hash
3. Commands in Makefile, scripts, docker images, etc using curl/wget.

2 and 3 may be done as part of a new code scanning check instead.

[laurentsimon]

TODO: frozen_deps.go#L207 and frozen_deps.go#L220

[rarkins]

I came here after looking for a place to comment about pinning hashes. Seems to be some overlap between issues.

I think OSSF could consider introducing/defining at least one more term in addition to "pinning". What we're really trying to achieve here is deterministic dependency use (i.e. get the same dependencies installed on all machines, for all time), which is similar but not as strong as reproducible builds - which take into account more than just dependencies.

Another way of framing it is that any dependency whose tag or version is not immutable should be pinned to a hash/digest. Examples:

• Git/GitHub tags
• Docker tags
• GitHub Actions

For example, if I depend on @foo/bar@1.0.0 on npmjs, I can reasonably expect that to be immutable and safe. If instead in the same package.json I depend on foo/bar#1.0.0 then that resolves to a tag https://github.com/foo/bar#1.0.0 which could change, and it's not safe/reliable.

In Renovate we've always favored pinning, but distinguish between pinning versions and pinning digests. We also recognize that many users resist this, so it's not our opinionated default. Adding support to automatically pin and then maintain/update GitHub Actions is a recent feature, for example - we added it out of a security concern of our own.

[laurentsimon]

if I depend on @foo/bar@1.0.0 on npmjs, I can reasonably expect that to be immutable and safe.

This depends on the threat model: how much trust do you want to put in the package manager's infra/database? Not everyone agrees here either.

[naveensrinivasan]

Related #664