RC npm: lockfiles or no lockfiles

[laurentsimon]

(Note: I will leave aside the npm-shrinkwrap.json since it's discussed separately in #10)

In this issue, I'd like to propose a change to the recommendation w.r.t lockfiles.
Originally, the OSSF (e.g., via the Scorecard's Pinned-Dependency checks) encourages lockfiles, a.k.a. "hash dependency pinning".

There has been feedback, e.g. by @ljharb in ossf/scorecard#1826 (comment) and #10 (comment) that lockfiles, in some scenarios, have disadvantages.

The main drawback highlighted by @ljharb is dev lock files. A dev lockfile is one that is used by the maintainer of a project, call it P. P relies on a set of dependencies, PPs. All tests may be passing for the maintainers of P, yet some bugs are reported by consumers because of a drift in PP versions.

As a results, consumers have a poorer experience, since they hit bugs they need to fix in prod, etc. @ljharb describes it as `` it's [...] important than ensuring that maintainers are notified as early as possible about issues in their dep graph.`.

The main advantages of lockfiles are the following:

• incidence response (Concerns about metrics from @ljharb scorecard#1826): engineers can quickly identify the list of hashes that made use of a malicious package
• avoids immediate (potentially malicious) package updates to prod (integration tests cannot catch malicious intent)

Since the benefit of lockfiles is prod and their absence is motivated by development practices, I'd like to suggest rephrasing the recommendation to the following
We recommend using a lock file in privileged environments, such as:
production environments
Other environments with access to sensitive data, such as secrets, PII, write/push permission to the repository, etc

The use of a lock file has the following benefits:
In an incidence response, it helps identify vulnerable packages that have been used, using the sha512
It reduces the chance of pulling in new-compromised packages published by an attacker.

In a non-privileged environment, developers may not use a lock file. This is useful if you want to exercise a wide range of dependency ranges, to anticipate breaking before your users do. If you run CI via GitHub Actions, a non-privileged environment is one of the following:
Pull_request trigger
Other triggers without secrets or permissions explicitly declared as read (default permission is write-all)